Accessing module internals from bytecode rewriting agent
Alan.Bateman at oracle.com
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 core-libs-dev