META-INF/MANIFEST.MF must include Dependencies: jdk.unsupported

[redmitry]

Hello,

Classgraph uses sun.misc.Unsafe which use is moved to jdk.unsupported module.
Latest WildFly builds (>=29) became quite strict in providing access to jdk.unsupported by default.

In my case I use eclipse/jnosql library which uses classgraph and without putting Dependencies: jdk.unsupported into the classgraph MANIFEST.MF deployment fails.

Best,

Dmitry

https://groups.google.com/g/wildfly/c/V8zQOFwpym0

[lukehutch]

Hi,

ClassGraph already depends upon jdk.unsupported:

classgraph/src/module-info/io.github.classgraph/module-info.java

Line 44 in 8360c03

requires jdk.unsupported;

If you need a different fix, it would be great if you could please figure out what exactly needs changing in ClassGraph, and please submit a PR. Thanks!

[lukehutch]

From the stacktrace in that groups discussion:

at deployment.beacon-nosql-server-2.0.4.war//nonapi.io.github.classgraph.utils.FileUtils.lookupCleanMethodPrivileged(FileUtils.java:529)

This makes it look like deployment.beacon-nosql-server-2.0.4.war actually repackages ClassGraph, without properly adding its module-info.java module dependencies to the war. If so, this is a bug in that library, not ClassGraph.

[redmitry]

Hi Luke,

What do you mean as "repackage"? The deployment.beacon-nosql-server-2.0.4.war includes the jnosql lib which depends on classgraph.

The war application shouldn't care whether some library is using jdk.unsupported module.
That's true, that including Dependencies: jdk.unsupported into the war /META-INF/MANIFEST.MF solves the problem, as well as putting it into the classgraph.jar /META-INF/MANIFEST.MF.
IMHO it's better the latter.

Ragarding the io.github.classgraph module export, the exception is in the nonapi.io.github.classgraph.utils.FileUtils which has no module defined.

I am not sure if providing /classgrath/src/module-info/nonapi/io/github/classgraph/utils/module-info.java is a right way.
I only may confirm that adding Dependencies: jdk.unsupported into the classgraph.jar MANIFEST.MF makes WildFly deployer happy.

Kind regards,

Dmitry

[lukehutch]

OK, I'm adding all the dependencies that are specified in module-info.java.

In the maven-jar-plugin config section of ClassGraph's pom.xml, I added the following (which will be turned into a Dependencies: line in the manifest file):

<Dependencies>java.xml,jdk.unsupported,java.management,java.logging</Dependencies>

Is the Dependencies: key a WildFly-specific thing? It is non-standard, and I can't find it documented anywhere.

Specifically, the things I wanted to find in the documentation are:

1. Are the dependencies supposed to be comma-separated?
2. Are the dependencies supposed to be package names, or Java module names?

[redmitry]

I understand this is WIldFly specific:
https://docs.wildfly.org/30/Developer_Guide.html#JAX_WS_JBoss_Modules_and_WS_applications

1. according the doc yes - packages comma-separated.
2. module names.

Thinking again, maybe you are right and this shouldn't be in the classgraph's manifest ...
Could "requires transitive jdk.unsupported;" help?

[lukehutch]

I have no idea, can you test that please?

Wildfly shouldn't need anything in the manifest if it is loading ClassGraph as a module, because those dependencies are in the module descriptor.

You mention packages in your answer to question 1, then module names in your answer to question 2... I'll assume you meant module names in both cases..

Can you please link to the docs?

[redmitry]

You mention packages in your answer to question 1, then module names in your answer to question 2..

Yes should be modules.

Some documentation from IBM / RedHat:
https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.4/html/development_guide/class_loading_and_modules#add_an_explicit_module_dependency_to_a_deployment

"Add a dependencies entry to the MANIFEST.MF file with a comma-separated list of dependency module names:"

Dependencies: org.javassist, org.apache.velocity, org.antlr

I am afraid WildFly doesn't support java modules natively.

For the moment I stick with putting Dependencies: into the WAR MANIFEST.MF.

Kind regards,

Dmitry

[lukehutch]

OK, so Dependencies: must be a JBoss-specific thing then.

I added all the other module dependencies too. Thanks!

Fixed and released in 4.8.165.