Accessing module internals from bytecode rewriting agent

[Jeremy Manson]

On Mon, May 8, 2017 at 5:54 AM, dalibor topic <dalibor.topic at oracle.com>
wrote:

> On 05.05.2017 08:39, Jeremy Manson wrote:
>
>> 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.
>>
>
> Indeed - thank you for providing valuable insight into your concerns and
> experiences.
>
> 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.
>>
>
> I think part of responsibly relying on awful hacks leveraging unsupported
> behavior is to budget for their removal/rewrite as the assumptions behind
> them get invalidated over time.
>

And we generally do go through this at every JDK release cycle.  This is
hardly the only time we've had to do a lot of unpleasant work.  A fun one
was in the Java 6->7 timeframe, when it turned out the fact that the JDK
iterated over methods in approximately-declaration order spilled over into
many, many tests, even though that was implementation-dependent behavior.
There was a very painful cleanup for everyone working on Java here.

We didn't mind doing that, because we knew it was an important part of the
metaspace work.  However, we did put in a JDK flag to mimic the old
behavior, for transitional purposes.

Sometimes, it might be well known where the awful hacks are buried, in
> particular with one's own code. Other times, in particular with third party
> code, it might not be quite as obvious. That's where the jdeps & jdeprscan
> tools come in to help get a sense of the scope & intensity of such problems
> at compile time.
>
> The kill switch complements that at runtime.


I'm sure we can mostly work around the compile-time stuff.  Similar
situations arise whenever an unsupported method is removed or changed.  I
recall we had to orchestrate a migration to javax.imageio from (something
else? can't remember) when we moved to OpenJDK.  We now have the moral
equivalent of a lot of unsupported methods being removed - even though they
aren't being removed, they are being hidden.  In general, I don't think it
is worth complaining about that, especially since we have the kill switch.

We shouldn't have much problem analyzing our dependencies - we build
everything feasible from source at head, and have a very comprehensive
suite of tests, so if there is a broken dependency in third party code, we
should know immediately.

In general, our upgrade strategy involves getting the world into a state
that works with both JDKs, and then switching the JDKs out from
underneath.  We are most likely to have to put our own hacks in the JDK for
the things for which "what you do in Java 8" and "what you do in Java 9"
can't be the same (or getting them to be the same is very difficult, or a
bad idea).

>From that perspective, the bootclasspath situation is interesting.  There
is no Xbootclasspath/p flag in Java 9, and no --add-exports or
--patch-module in Java 8, so there is no state that will work with both.
We could comb through every use in our repo, and add extra code to detect
which JDK we are using / switch between them.   Then, after the transition,
we could delete all of that extra code.  However, that would be
meaningfully harder than just putting Xbootclasspath/p back for the
transition, and it would leave our command lines less readable.  The better
thing for us to do is almost certainly to allow users to use
Xbootclasspath/p until we kill Java 8 internally.

Turning the big kill switch on by default, by comparison, is more similar
to the method iteration situation in Java 7; if we work hard, we can
probably get the world into a single state that will work without making
everyone's code worse.  However, doing that migration up front would be a
headache that will take time, and, typically, the more time we take, the
more incompatibilities crop up.  So, starting with the kill switch on by
default should be a time saver.

Jeremy


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