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
deprecated.
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 [1].
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.
-Alan.
[1] http://openjdk.java.net/jeps/261
