Accessing module internals from bytecode rewriting agent

[Jeremy Manson]

Brian:  Bit of a miscommunication on my part: I know 8 can deal with
multirelease JARs.  I just can't build them with 8 (although maybe I could
with enough build magic).  When I said "rely on another 9 feature", I just
meant that I would be building something else in that required 9, which
would be bad because I would require a pre-release 9 to build.  I'm not
going to inflict that on my users (many of whom have forked it and build it
themselves).

(This project isn't Guava or Dagger or something - it's just a small-ball
instrumentation agent.)

Alan: Most of our code runs with our home-grown launcher (so we can take
advantage of JEP 178) and an OpenJDK-based JVM, although we also still
build and distribute the OpenJDK launcher, and many people use it.  People
are using Xbootclasspath for a variety of things.  We use it in various
non-OpenJDK libraries configurations (like with GWT and j2objc) to run with
their class libraries, which are not OpenJDK-based.  We also have folks
using Jetty ALPN, which requires it.  We also have a bunch of people using
it for instrumentation agents (it's a little tricky to get
X-Boot-Class-Path to work in our environment), but there should be
workarounds for that.  We have a few people using it for...
not-immediately-obvious reasons.

I didn't realize that bootclasspath/a still partially worked - that might
be enough for some of these use cases.  We'll have to see when we get to
it.  And see what happens when the stuff hits the fan.

We don't actually use javac at all - we have our own wrapper around the
javac API.

Anyway, I can see we have an interesting upgrade path ahead of us.  I'm
glad that we solved so many recurring problems permanently (like our hash
randomization change).

Jeremy


On Tue, May 2, 2017 at 7:51 AM, Brian Goetz <brian.goetz at oracle.com> wrote:

> 8 can deal with multi-release JARs.  The extra goop is ignored.  So a
> 7/8/9 MRJar is perfectly possible (and in fact, the whole point of doing
> them in the first place, so library writers could publish JARs that span
> 7/8/9.)
>
>
> On 5/2/2017 2:50 AM, Jeremy Manson wrote:
>
> Maybe when there's something breaking in Java 10 or 11, I can do that.
> Right now, that approach requires me to have a fork of my code, have
> special build goop, rely on yet another Java 9 feature, and make my
> relatively widely used OSS project require Java 9 to build *prior to Java
> 9's release -* just so I can save maybe 15-20 lines of code.
>
> Meanwhile, I'm not having a lot of luck - adding what seems to be the
> right reflective call doesn't seem to allow me to modify classes like
> ArrayList.  Trying to create a boiled down repro (in 30 minute chunks
> between management tasks - sigh).
>
> OffTopic, but possibly of interest to you: it has also been challenging to
> figure out how we're going to migrate our users away from features like
> Xbootclasspath.  Our standard operating procedure (which has worked from 5
> to 6 to 7 to 8) is to get the codebase into a state where it can work both
> with the previous version and the new version of the JDK, and then throw
> the switch.
>
> If we follow this path, before we migrate to Java 9, we would need to make
> sure all of our code builds and the tests pass with Java 9 and Java 8.  We
> can't make all of the code build and the tests pass with Java 9 as-is,
> because many of them use options like Xbootclasspath, which have been
> dropped.  We can't migrate those tests to use the new command line flags
> before we migrate to Java 9, because if we do, they will stop working with
> Java 8.  Due to the size of our code base, it's pretty much impossible to
> migrate all of the users to a new set of command line flags at the same
> time as we migrate to Java 9.
>
> Between that and the amount of reflective access we do into the JDK, we'll
> probably just end up re-adding features like Xbootclasspath in our fork and
> enabling the big kill switch for everyone, and then removing it gradually
> over the lifetime of Java 9.  We've had to do that for some minor stuff
> before, but nothing this big.  I'm glad we have options like that, and
> don't envy people with large codebases who don't.
>
> That said, we probably abuse the ability to crack open the JDK more than
> most people.
>
> I've been dealing with some of the concerns about upgradability for some
> of Google's open-source projects lately, and I am insisting that we have a
> rule that there is always an intermediate version that provides backwards
> compatibility for any desired change, so that users can always perform
> stepwise migrations.  Thanks for the inspiration. :)
>
> Jeremy
>
> On Mon, May 1, 2017 at 5:38 PM, Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>> Or use multi-release JARs.
>>
>>
>> On 4/25/2017 3:14 AM, Jeremy Manson wrote:
>>
>>> I guess I can call it reflectively.
>>>
>>
>>
>
>