Accessing module internals from bytecode rewriting agent

[Brian Goetz]

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