Bug in ClassPathContext?

[mark.reinhold at oracle.com]

Chasing down a couple of failing unit tests, I ran across this code in
org.openjdk.jigsaw.ClassPathContext:

    private static String[] toolsModules() {
        // jdk.tools.jre is not in this list because its classes are 
        // included in rt.jar in the legacy image.
        String[] modules = new String[] {
            "jdk.tools.base", "jdk.tools.jaxws", "jdk.tools", "jdk.devtools"
        };
        // ## modulepath
        // JDK development build - all classes are loaded by bootstrap loader
        return file("classes") != null ? modules : new String[0];
    }

I suspect the last comment and the last statement to be incorrect.  Now
that the VM is loading classes directly from module libraries, even in
a development build, the $BUILD/classes directory is irrelevant to a
running VM even in class-path mode, right?

There's similar code in the nearby extModules() method.

FYI the failing tests try to use com.sun.tools.javac.Main.  If I move
the classes directory, or use the jdk module image, then the test
passes.  The jdk.classpath context does, correctly, have an optional
dependence upon the jdk.devtools module, which is where javac lives.

- Mark