Accessing module internals from bytecode rewriting agent

[Jeremy Manson]

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