-Xbootclasspath/p: (or similar) please

[Jonathan Gibbons]

Rémi Forax wrote:
> Le 26/03/2010 21:33, Jonathan Gibbons a écrit :
>> 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
>
> +1
> Patching anything in the JDK without -Xbootclasspath takes a loooong 
> time.
>
> Also some languages that run on top of the VM like JRuby or Jython
> put their own runtime in the boot classpath.
>
> Rémi

I would expect that any software packages that get delivered to the end 
user would include a module that can be installed, so that it is not 
necessary to put classes on the bootclasspath. After all, we *are* 
trying to eliminate "jar hell".  The issue is arguably less clear for 
software that is of a transitory nature, such as a patch being tested.  
In this case, a little bit of carefully controlled "jar hell" may be 
good for the sole time the patch is going to be run.

-- Jon