Should ClassPath.getTopLevelClasses() return `java.*` packages?

Question

I'm using guava's ClassPath to retrieve available classes. With Java 8, this worked well, but I'm migrating to Java 10, and now it doesn't work. I've tried both guava 24.1 (the latest jarfile available on Maven Central) and the latest sources on github (as of April 27th 2018) -- presumably more or less guava 25.0, given they released it yesterday.

I can retrieve some classes, but anything in any java.* packages fail to appear. Is this is actually a bug, or am I using Java 10 wrong (i.e., does modularity mean I need to do something special)? I see the same symptom in Java 9. I've tried building and running with Java 10 (or 9) as well as building with Java 8 and running with Java 10 (or 9), the behaviour is the same either way.

I've set up a dummy example with two classes in packages com.just.me and com.just.another:

com.just.me.Main.java

package com.just.me;

import com.google.common.reflect.ClassPath;
import com.just.another.Dummy;
import java.lang.String;
import java.util.Collections;
import java.util.List;

import java.io.IOException;

public class Main {

    public static void main(String[] args) {
        List<String> dummyList = Collections.emptyList();
        printClassCount("com.just.me", Main.class);
        printClassCount("com.just.another", Main.class);
        printClassCount("com.just", Main.class);
        printClassCount("com.google", Main.class);
        printClassCount("java.lang", Main.class);
        printClassCount("java.util", Main.class);
        printClassCount("java", Main.class);
    }

    private static void printClassCount(String packageName, Class classForClassLoader) {
        System.out.println("Number of toplevel classes in " + packageName + ": " + countTopleveClassesInPackage(packageName, classForClassLoader));
    }

    private static int countTopleveClassesInPackage(String packageName, Class clazz) {
        try {
            ClassPath classPath = ClassPath.from(clazz.getClassLoader());
            return classPath.getTopLevelClassesRecursive(packageName).size();
        } catch (IOException e) {
            return 0;
        }
    }
}

com.just.another.Dummy.java

package com.just.another;

public class Dummy {
    private String s;
    Dummy(String s) {
        this.s = s;
    }

    @Override
    public String toString() {
        return s;
    }
}

Output (Java 8)

Number of toplevel classes in com.just.me: 1
Number of toplevel classes in com.just.another: 1
Number of toplevel classes in com.just: 2
Number of toplevel classes in com.google: 569
Number of toplevel classes in java.lang: 232
Number of toplevel classes in java.util: 367
Number of toplevel classes in java: 1878

Output (Java 9/10)

Number of toplevel classes in com.just.me: 1
Number of toplevel classes in com.just.another: 1
Number of toplevel classes in com.just: 2
Number of toplevel classes in com.google: 569
Number of toplevel classes in java.lang: 0
Number of toplevel classes in java.util: 0
Number of toplevel classes in java: 0

The javadoc for ClassPath lists several limitations, one of which is that the ClassLoader must be of type URLClassLoader. The java.* classes are defined by the boot and platform class loaders, neither of which are instances of URLClassLoader. — Alan Bateman, Apr 28 '18 at 06:56
Sounds to me like a bug, but a known bug that they haven't figured out how to fix yet. — rainbowgoblin, Apr 30 '18 at 00:58
It looks like a contradiction to pass an application class as reference for listing bootstrap classes. In this case, the actual type of the application loader doesn’t matter. But it’s not impossible to get the classes, i.e. `Files.list(Paths.get(URI.create("jrt:/modules/java.base/java/lang"))) .map(p -> p.getRoot().resolve("modules/java.base").relativize(p).toString()) .filter(s -> s.endsWith(".class")) .map(s -> s.substring(0, s.length()-6).replace('/', '.')) .forEach(System.out::println);` lists all classes of `java.lang`. See also [this answer](https://stackoverflow.com/a/36021165/2711488)… — Holger, May 07 '18 at 09:22

score 1 · Accepted Answer · answered May 24 '18 at 05:26

I think, there is no bug in ClassPath. It represents a classpath but system classes are not on the classpath in Java 10:

// doesn't print rt.jar because there is no rt.jar anymore
System.out.println(StandardSystemProperty.JAVA_CLASS_PATH.value());

So this is correct behavior that getTopLevelClasses does not return any classes for the java.* package.

If you still want to list top-level system classes, you can do something like that (not exact code, just a sketch):

FileSystem fs = FileSystems.getFileSystem(URI.create("jrt:/"));

Files
    .list(fs.getPath("modules", "java.base", "java/lang"))
    .map(Path::getFileName)
    .filter(p -> p.toString().endsWith(".class") && !p.toString().contains("$"))
    .forEach(System.out::println);

Should ClassPath.getTopLevelClasses() return `java.*` packages?

com.just.me.Main.java

com.just.another.Dummy.java

Output (Java 8)

Output (Java 9/10)

1 Answers1