-Xbootclasspath/p: (or similar) please

[Jonathan Gibbons]

What are the limitations of the bootclasspath options in the jigsaw 
module images?

"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.

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

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.)

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.

-- Jon