Accessing module internals from bytecode rewriting agent

Remi Forax forax at
Wed Jun 14 05:43:05 UTC 2017

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 ?


----- Mail original -----
> De: "Jeremy Manson" <jeremymanson at>
> À: "dalibor topic" <dalibor.topic at>
> Cc: "core-libs-dev" <core-libs-dev at>
> 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 (
> 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>
> 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>
>> 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."
>>> va.html#BABHDABI
>>> cheers,
>>> dalibor topic
>>> --
>>> <> 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
>>> <> Oracle is committed to developing
>>> practices and products that help protect the environment

More information about the core-libs-dev mailing list