This is follow up to https://github.com/javamelody/javamelody/issues/1179

I think that the fact that sun.misc.Unsafe is inaccessible since WildFly v29 (WFCORE-6248) may be a problem, which should not need so much investigation and should not need to add `jdk.unsupported` in dependencies.

A problem because sun.misc.Unsafe is explicitly on the list of critical internal API, for which supported replacements did not exist in JDK 8, and which should be accessible until supported replacements exists. That rule was written in JEP 260 because otherwise a lot of third party libraries would fail without replacement solution. (sun.nio.ch.DirectBuffer is not on this critical internal API list and sun.misc.Unsafe#invokeCleaner was added just because of that.)

Ensure that critical, widely-used internal APIs are not encapsulated, so that they remain accessible until supported replacements exist for all or most of their functionality.
[...]
These APIs are defined in, and exported by, the JDK-specific jdk.unsupported module. This module is present in full JRE and JDK images. These APIs are thus accessible by default to code on the class path, and accessible to code in modules if those modules declare dependencies upon the jdk.unsupported module.
https://openjdk.org/jeps/260

I admit that JEP 260 suggests to declare dependencies upon the jdk.unsupported module, in the case of code in modules, instead of accessible by default in the case of code on the class path. But my opinion is that it should be something taken care of by WildFly by default more than by webapp developers, without a need on developers to investigate in modules and the know of jdk.unsupported.