overrideClassLoaders(AppClassLoader) not no-op with Java 11

This might just be a semantic issue, but it is an obvious change in behaviour vs running on Java 8.

We are executing ClassGraph as follows:

ClassGraph().overrideClassLoaders(classLoader)
    .ignoreParentClassLoaders()
    .enableClassinfo()
    .scan()

The classLoader is allowed to be AppClassLoader, and this isn’t a problem on Java 8. However, it does cause problems on Java 11. I have tested ClassGraph 4.8.58, 4.8.65 and 4.8.67, and none of them finds any nonSystemModuleRefs, although 4.8.67 does at least find the systemModuleRefs. (To be precise, ClassGraph does find lots of “unnamed modules” on the call-stack, but rejects them all because layer == null.)

We are working around this by doing the following:

ClassGraph().apply {
    if (classLoader !== ClassLoader.getSystemClassLoader()) {
        overrideClassLoaders(classLoader)
    }
}.ignoreParentClassLoaders()
 .enableClassinfo()
 .scan()

This works because it allows ClasspathFinder to consult the java.class.path system property and so populate the classpathOrder field instead. And to be clear, these are the jars we want to be scanning. We have no need to scan the systemModuleRefs here.

See #382 and #411.

[GedMarc]

@lukehutch Hey Luke, we pushed .68 into our production environment today on JLink JDK 14 😃

Still perfect! And still one of the only libraries that is keeping up with the pace of the new 6 month releases!

[chrisr3]

Thanks, my tests pass with the new changes. I was slightly concerned that

ClasGraph().apply {
    if (classLoader !== ClassLoader.getSystemClassLoader()) {
        overrideClassLoaders(classLoader)
    }
}

was adding an extra 20 elements to the order than

ClasGraph().overrideClassLoaders(classLoader)

does when classLoader is AppClassLoader, but then I realised that these 20 jars were all Gradle and so their exclusion was a Good Thing ™️!

I like it! I like it a lot… 👍