Accessing module internals from bytecode rewriting agent

[Jeremy Manson]

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?

(Again, our control means that we can just add it back for our builds, but
I'd rather do something available in a stock JDK...).

Jeremy


On Thu, May 4, 2017 at 11:39 PM, Jeremy Manson <jeremymanson at google.com>
wrote:

> Thanks, Dalibor.
>
> I know it may sound surprising, but I'm not actually complaining.  I do
> understand that most everything we're doing that requires workarounds for
> modules is unsupported (with the possible exception of the changes to
> instrumentation agents), and we were always doing them at our own risk.
> This is far from limited to Xbootclasspath - we have all sorts of hacks,
> including, to pick two things at random among many, code that introspects a
> Thread's Runnable to pick a good name to report for a thread, and code that
> introspects an AbstractInterruptibleChannel to stop the owning thread from
> closing the channel when it gets an interrupt.
>
> It's our problem to fix these issues, and I'm unlikely to claim
> otherwise.  Frankly, it doesn't seem all that difficult to find other ways
> to introspect into the JDK - it's just busywork and more awkward than it
> used to be.
>
> Mostly, I'm telling you all because I think it makes an interesting case
> study - a large Java installation and the issues it faces trying to roll
> out JDK 9.
>
> If other installations do the kinds of things that we do, the path to a
> JDK 9 without lots of add-exports and kill switch options is likely to be
> slow and laborious for them.  We're comparatively well situated to do it -
> we have our own JDK build and a staffed team to do / help with the
> migration, and are likely to roll it out to everyone with the kill switch
> turned on by default so that our awful hacks can stay put until we finish
> fixing them.
>
> (Also, if I were complaining, there would have been a lot of choice things
> I would have said that I'm not going to say. :) )
>
> Jeremy
>
> On Thu, May 4, 2017 at 4:35 AM, dalibor topic <dalibor.topic at oracle.com>
> wrote:
>
>> On 02.05.2017 18:46, Jeremy Manson wrote:
>>
>>> People
>>> are using Xbootclasspath for a variety of things.
>>>
>>
>> It's worth keeping in mind when using such options that
>>
>> "Non-standard options are general purpose options that are specific to
>> the Java HotSpot Virtual Machine, so they are not guaranteed to be
>> supported by all JVM implementations, and are subject to change. These
>> options start with -X."
>>
>> http://docs.oracle.com/javase/8/docs/technotes/tools/unix/ja
>> va.html#BABHDABI
>>
>> cheers,
>> dalibor topic
>> --
>> <http://www.oracle.com> Dalibor Topic | Principal Product Manager
>> Phone: +494089091214 <tel:+494089091214> | Mobile: +491737185961
>> <tel:+491737185961>
>>
>> ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg
>>
>> ORACLE Deutschland B.V. & Co. KG
>> Hauptverwaltung: Riesstr. 25, D-80992 München
>> Registergericht: Amtsgericht München, HRA 95603
>>
>> Komplementärin: ORACLE Deutschland Verwaltung B.V.
>> Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
>> Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
>> Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher
>>
>> <http://www.oracle.com/commitment> Oracle is committed to developing
>> practices and products that help protect the environment
>>
>
>