Using Java 11, we've found that our integration tests using WildFly 18 run correctly and provide the instrumentation and reports when using the OpenJDK11-Hotspot VM JDK.
However, if we run the same build with the OpenJDK-11-J9 VM (the eclipse J9 runtime) - this occurs:
INFO: Starting container with: [C:\Development\Java\JDK\bin\java, -D[Standalone], -Xmx10G, -Djava.library.path=C:\\Development\\WildFly\\standalone\\lib, -javaagent:C:\\Development\\portal\\libs\\DB\\target\\jacocoagent-0.8.5.jar=destfile=C:\\Development\\portal\\libs\\DB\\target\\jacoco.exec, -ea, -Djboss.home.dir=C:\Development\WildFly, -Dorg.jboss.boot.log.file=C:\Development\WildFly\standalone\log\server.log, -Dlogging.configuration=file:C:\Development\WildFly\standalone\configuration\logging.properties, -jar, C:\Development\WildFly\jboss-modules.jar, -mp, C:\Development\WildFly\modules, org.jboss.as.standalone, -Djboss.home.dir=C:\Development\WildFly, -Djboss.server.base.dir=C:\Development\WildFly\standalone, -Djboss.server.log.dir=C:\Development\WildFly\standalone\log, -Djboss.server.config.dir=C:\Development\WildFly\standalone\configuration]
Exception in thread "main" java.lang.NoClassDefFoundError: java.lang.$JaCoCo
at org.jboss.logmanager.LogManager.$jacocoInit(LogManager.java)
at org.jboss.logmanager.LogManager.<clinit>(LogManager.java)
at java.base/java.lang.J9VMInternals.newInstanceImpl(Native Method)
at java.base/java.lang.Class.newInstance(Class.java:2082)
at java.logging/java.util.logging.LogManager$1.run(LogManager.java:239)
at java.logging/java.util.logging.LogManager$1.run(LogManager.java:223)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:678)
at java.logging/java.util.logging.LogManager.<clinit>(LogManager.java:223)
at org.jboss.modules.Main.main(Main.java:523)
Caused by: java.lang.ClassNotFoundException: java.lang.$JaCoCo from [Module "org.jboss.logmanager" version 2.1.14.Final from local module loader @4f93e763 (finder: local module finder @cbe6fdc3 (roots: C:\Development\WildFly\modules,C:\Development\WildFly\modules\system\layers\base))]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:255)
at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:410)
at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:398)
at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:116)
... 9 more
We had a very similar issue with another instrumentation library on our production machines (DynaTrace app monitoring) but were able to fix that by modifying the startup parameters (adding the logging/modules/Xbootclasspath options you see above).
Have we stumbled into an incompatibility with Jacoco, or just not hit on the exact configuration syntax? Please advise so I can either give up, provide more info, or file a bug report.