-Xbootclasspath/p: (or similar) please

[Rémi Forax]

Le 26/03/2010 23:49, Jonathan Gibbons a écrit :
> 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.

JVM language runtimes are often more than sofware packages and use nasty 
tricks like
accessing to jdk internals (sun.misc.unsafe) or relying on bytecode 
injection, etc.

>
> -- Jon

Rémi