Accessing module internals from bytecode rewriting agent

[Remi Forax]

Hi Jeremy,
adding several --patch-module and a -XX:+IgnoreUnrecognizedVMOptions to the command lines that contains -Xbootclasspath/p should work for both 8 and 9 VMs, no ?

Rémi

----- Mail original -----
> De: "Jeremy Manson" <jeremymanson at google.com>
> À: "dalibor topic" <dalibor.topic at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Mercredi 14 Juin 2017 01:57:55
> Objet: Re: Accessing module internals from bytecode rewriting agent

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