-Xbootclasspath/p: (or similar) please

[Mandy Chung]

Jonathan Gibbons wrote:
> What are the limitations of the bootclasspath options in the jigsaw 
> module images?
>

bootclasspath continues to work as it is today in legacy mode.  
bootclasspath is not supported in module mode.
> "java -X" says they cannot be used when executing a module.  Does that 
> also apply when the module is implicit, as in tools invoked by the 
> launcher, like javac, javadoc, etc.

I converted most of the jdk tools to run in module mode and 
-J-Xbootclasspath can no longer be passed to those tools running in 
module mode.

If a tool remains in legacy mode, it will continue to accept 
-J-Xbootclasspath option.

>
> If so, can I put it a BIG request that -Xbootclasspath/p: or an 
> equivalent should be supported.  I think it is CRITICALLY important 
> for JDK developers to have a way of substituting new classes for 
> existing ones when working on bug fixes and similar work.

Completely agree.
>   In the jdk/ repo I know that folk tend to do a partial build and 
> execute out of the "build/classes/" directory.  This will not work in 
> the modules world. 

We talked about implementing the "zero mod" facility (currently in 
javac) in the Java launcher so that we can say something like:

   $ java -L $OUTPUTDIR/modules MyUnitTest

> In the langtools/ repo, we routinely compile just the langtools 
> classes and execute them with a existing JDK using 
> -Xbootclasspath/p.   The limitation on -Xbootclasspath means that this 
> too will not work in the modules world.
>
I would imagine that we could do something like this for langtools:

   $ java -L langtools/dist/modules JavacTest

I haven't put much thought about this though and there are possibly 
issues to be resolved.  Hmm.... javac and other jdk tools take 
-J<argument> and pass the argument to the launcher invoking the tool.  I 
don't think we can prepend  "-L <module-lib>" with -J.

> Development will be severely impacted if we have to build new modules 
> images every time we want to try out a fix.
>
> From a testing point of view, I know that most of the langtools tests 
> exercise functionality that is independent of whether JDK is running 
> in legacy mode or modules mode. But, currently 31 tests fail in 
> modules mode. These tests do not fail in legacy mode.  This means the 
> fixes for these tests will need to be tested on a full modules build.  
> Starting from scratch, a full modules build takes me about an hour, 
> whereas building langtools and using -Xbootclasspath typically takes 
> under half a minute. (That's a factor of 100 or more faster.)
>

My bad.  I ought to speed up the modules build to help our development.  
It's on my list to work on.  Mark also has a patch to replace cpio with 
rsync to improve the subsequent modules build time.

> In javac, it proved necessary to implement -Xbootclasspath options 
> even in module mode (Note, I mean the javac options here, not the 
> underlying JVM options). In practice, it was reasonably easy to 
> augment the search for platform classes with the extra locations being 
> provided by -Xbootclasspath, and -Xbootclasspath/p: in particular.  
> Surely it is possible to do something similar in the JVM. It might be 
> idealistic to say we should not to subvert the classes provided by the 
> module system, but pragmatically, there are times when it will be 
> necessary.
>

I would hope that there is a way to address this requirement in the 
modules world while not needed to keep bootclasspath :)

Mandy