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" <jeremyman...@google.com> > À: "dalibor topic" <dalibor.to...@oracle.com> > Cc: "core-libs-dev" <core-libs-dev@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 <jeremyman...@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.to...@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 >>> >>
