@skahmann Thanks for this contribution. Will I need to replace all uses of classes in these packages with reflective access and a sane fallback, for OSGi environments that do not contain these packages?

@skahmann Actually I checked, and all the access to these classes is already via reflection, with a sane fallback (requiring garbage collection to unmap byte buffers, rather than explicitly unmapping them).

However, the module descriptor still uses:

    // VersionFinder requires java.xml
    requires java.xml;
    // FileUtils requires jdk.unsupported (for usage of Unsafe)
    requires jdk.unsupported;
    // ModulePathInfo requires java.management
    requires java.management;
    // LogNode requires java.logging
    requires java.logging;

Replacing these with requires static may make ClassGraph projects fail even if the module is available, if some other module in the classpath has not already requires-ed the module.

Is it safe to assume that OSGi projects will never use JPMS modules, and continue using the legacy classpath?

I did some testing using Apache Karaf and everything seems to be working okay. I think it's safe to assume the OSGi runtime makes these classes available. I was tuned into this fix based on this issue: assertj/assertj#1663

@skahmann Thanks. Ș do this question:

Is it safe to assume that OSGi projects will never use JPMS modules, and continue using the legacy classpath?