Bug in ClassPathContext?

[Mandy Chung]

On 10/10/2012 2:55 PM, mark.reinhold at oracle.com wrote:

> 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?

You're right - the last statement doesn't match the comment. I haven't
been able to understand why the unit tests have been passing
with jdk-module-image (no $BUILD/classes directory and also JPRT build)
in my testing before the push. Hmm.. all modules are loaded by the
bootstrap null loader except and so that works.

Are the unit tests failing with jigsaw/jigsaw tip?  I'm going to fix it.


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

yes.


> 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.
I ran into those failing tests during the development of the classpath
mode and thought that fixed properly.  Sorry - one of those mistakes.

Mandy