Accessing module internals from bytecode rewriting agent
Alan.Bateman at oracle.com
Wed Jun 14 07:45:02 UTC 2017
On 14/06/2017 00:57, Jeremy Manson wrote:
> Hey folks,
> As a followup to this, given everything else that has happened in the mean
> time: I wonder if the same logic Mark put in his proposal to allow illegal
> access to internal APIs (
> http://mail.openjdk.java.net/pipermail/jigsaw-dev/2017-June/012841.html) in
> JDK 9 also applies to Xbootclasspath/p.
> Mark's stated goal in his revised proposal is to address concerns that code
> that works on JDK 8 today will not work on JDK 9 tomorrow, yet no advance
> warning of this change was given at run time in JDK 8. No advance warning
> was given for the removal of -Xbootclasspath/p, and, without it, there will
> need to be a lot of fiddly logic in a lot of scripting languages to allow
> for testing to switch between Java 8 and Java 9.
> Dalibor's previous response of "-X options are subject to change" is
> probably not relevant, given the fact that everything that is being done
> via access to internal APIs is subject to change, and Mark's proposal is
> probably the way Java 9 will be rolled out.
> There are plenty of XX flags that aren't removed without warning, too:
> -XX:+UseConcMarkSweepGC is going to spend an entire release cycle
> Would it make sense to make -Xbootclasspath/p available again, possibly
> only if the kill switch is enabled?
There is no proposal to bring back the unsupported -Xbootclasspath/p.
That option was for overriding classes defined to the boot loader,
something that doesn't make sense with JDK 9 where the boot class path
is mostly gone and where many of the APIs that could potentially be
patched via -Xbootclasspath/p are not defined to the boot loader
anymore. As Remi note, the option to look at is -patch-module option,
the details are in JEP 261 .
As regards --illegal-access then there is no connection. That proposal
just opens the packages that existed in JDK 8 to allow code that hacks
JDK internals (with core reflection mostly) to continue to work for a
bit longer. It doesn't change anything else.
More information about the core-libs-dev