-Xbootclasspath/p: (or similar) please
Jonathan.Gibbons at Sun.COM
Fri Mar 26 15:49:09 PDT 2010
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
> Patching anything in the JDK without -Xbootclasspath takes a loooong
> Also some languages that run on top of the VM like JRuby or Jython
> put their own runtime in the boot classpath.
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.
More information about the jigsaw-dev