Accessing module internals from bytecode rewriting agent

[Jeremy Manson]

Hey folks,

I understand that -patch-module accomplishes similar goals.  The point I
was making is that it can be a pain to change deployment / testing scripts
that contain command line flags to have two different versions of those
flags, which get chosen depending on what JDK you are running.

In fact, given our codebase, it will be likely to be a bigger job for us to
deal with the -Xbootclasspath/p flag transition than to deal with a lot of
the other transition problems that are fixed by Mark's proposal.
Introspection into the JDK happens in a small number of places.  You may
have to be a bit clever about how you fix it, but they are generally
fixable.  By contrast, there are hundreds of little snippets of shell we
have to change to get rid of Xbootclasspath/p.

And given that you want both JDK 8 and JDK 9 working at the same time, you
have to make two passes over all that shell: one to make sure both versions
are supported, and then a second one later to remove the JDK 8 support.

It would be much easier for us to leave -Xbootclasspath/p in place, and
then fix it all once we've finalized the transition, but before Java 10
comes out.

The upshot is that, in the same way as we would have turned on the big kill
switch by default to ease the transition, we are also likely to implement
-Xbootclasspath/p to ease the transition.  I note that you came around on
the big kill switch being on by default for the transition, so I thought
you might also come around on continuing to provide -Xbootclasspath/p for
the transition.

Jeremy

On Wed, Jun 14, 2017 at 12:45 AM, Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> 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
>
>
>
>