Accessing module internals from bytecode rewriting agent

Alan Bateman Alan.Bateman at
Tue May 2 07:48:52 UTC 2017

On 02/05/2017 07:50, Jeremy Manson wrote:
> :
> If we follow this path, before we migrate to Java 9, we would need to 
> make sure all of our code builds and the tests pass with Java 9 and 
> Java 8.  We can't make all of the code build and the tests pass with 
> Java 9 as-is, because many of them use options like Xbootclasspath, 
> which have been dropped.  We can't migrate those tests to use the new 
> command line flags before we migrate to Java 9, because if we do, they 
> will stop working with Java 8.  Due to the size of our code base, it's 
> pretty much impossible to migrate all of the users to a new set of 
> command line flags at the same time as we migrate to Java 9.
So I'm curious about -Xbootclasspath as that completely overrides the 
runtime classes. Is this static instrumentation or combining the 
VM/launcher from one build with the classes from a different JDK build? 
In any case, and as you have found, -Xbootclasspath  and 
-Xbootclasspath/p are meaningless now, a consequence of moving all the 
core APIs to modules. The -Xbootclasspath/a option works as before with 
the caveat that not all platform classes are visible to the boot class 
loader now (a consequence of ongoing security work to move non-core 
components away from the fully privileged boot loader).

It might be that you mean the `javac -bootclasspath,  this works as 
before when you target 8 or older.


More information about the jigsaw-dev mailing list