-Xbootclasspath/p: (or similar) please

[Jonathan Gibbons]

Rémi Forax wrote:
> 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
Oh boy, what fun we have ahead ;-)

-- Jon