Javamelody 2.0.1/Jakarta EE 10/Java 17 about javamelody HOT 8 CLOSED

which jvm and version are you using exactly?

from javamelody.

openjdk version "17.0.8" 2023-07-18
OpenJDK Runtime Environment Temurin-17.0.8+7 (build 17.0.8+7)
OpenJDK 64-Bit Server VM Temurin-17.0.8+7 (build 17.0.8+7, mixed mode, sharing)

from javamelody.

same problem
openjdk version "17.0.8.1" 2023-08-24
OpenJDK Runtime Environment Temurin-17.0.8.1+1 (build 17.0.8.1+1)
OpenJDK 64-Bit Server VM Temurin-17.0.8.1+1 (build 17.0.8.1+1, mixed mode, sharing)

or

java 17.0.9 2023-10-17 LTS
Java(TM) SE Runtime Environment (build 17.0.9+11-LTS-201)
Java HotSpot(TM) 64-Bit Server VM (build 17.0.9+11-LTS-201, mixed mode, sharing)

from javamelody.

does not compile with Java 17
[ERROR] Failed to execute goal org.apache.maven.plugins:maven-compiler-plugin:3.11.0:compile (default-compile) on project javamelody-core: Compilation failure
[ERROR] C:\GIT\BO\TEST\javamelody\javamelody-core\src\main\java\net\bull\javamelody\internal\model\RrdNioBackend.java:[39,14] error: package sun.nio.ch is not visible
[ERROR] (package sun.nio.ch is declared in module java.base, which does not export it to the unnamed module)

from javamelody.

https://bugs.openjdk.org/browse/JDK-8171377

https://endoflife.date/oracle-jdk

Does it makes sense to support older Java versions ?

from javamelody.

As you have said, the log is WARNING: exception while collecting data: java.lang.IllegalAccessError: class net.bull.javamelody.internal.model.RrdNioBackend (in unnamed module @0x6cd25ae4) cannot access class sun.nio.ch.DirectBuffer (in module java.base) because module java.base does not export sun.nio.ch to unnamed module @0x6cd25ae4.
This log message is not explicit and is certainly misleading. Since you are using Java 17, the issue is in fact not that javamelody can not access sun.nio.ch.DirectBuffer, the issue is that javamelody can not access sun.misc.Unsafe, even if sun.misc.Unsafe exists in Java 17. (Since Java 9, javamelody needs access to sun.misc.Unsafe instead of sun.nio.ch.DirectBuffer to unmap DirectBuffer's file.)
_

About sun.misc.Unsafe access in Wildfly since Wildfly v29, see https://groups.google.com/g/wildfly/c/V8zQOFwpym0/m/p-ruN4JbCAAJ and https://issues.redhat.com/browse/WFCORE-6249, https://issues.redhat.com/browse/WFCORE-6248

I quote @bstansberry :

https://issues.redhat.com/browse/WFCORE-6249 is the reason you need to do this. WildFly used to add its own sun.jdk module as a dependency to all deployments, but that overly broadly breaks JDK encapsulation. Deployments can add dependencies on specific JDK JPMS modules they need by listing them in the 'dependencies' section of a jboss-deployment-structure.xml, as discussed in https://docs.wildfly.org/29/Developer_Guide.html#jboss-deployment-structure-file. In your case you'd name 'jdk.unsupported'. Since WildFly now requires SE 11 or later and all such SE versions provide curated-by-OpenJDK JPMS modules that can be depended upon, it's better that users specify which of those they need.

In case you ask, I could add entries in javamelody-core's MANIFEST, but I do not plan to add Wildfly specific entries.
So adding jdk.unsupported in the dependencies of your Wildfly v29+ is the way to go for you @dieter1963. Or you could add Dependencies: jdk.unsupported entry in your war file (using maven-war-plugin), according to the message in the group above.

About why javamelody still needs access to sun.misc.Unsafe since Java 9 to unmap DirectBuffer's file, you can see https://bugs.openjdk.org/browse/JDK-4724038 and the answer is JEP 454: Foreign Function & Memory API, which is still in preview (incubating).

from javamelody.

Issue created at RedHat for WildFly : https://issues.redhat.com/browse/WFCORE-6655

Copy:
This is follow up to #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.

from javamelody.

I will probably improve the message in the log. And closing this issue according to my #1179 (comment) above.

from javamelody.