Accessing module internals from bytecode rewriting agent
brian.goetz at oracle.com
Tue May 2 14:51:19 UTC 2017
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
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
> 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. :)
> 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.
More information about the core-libs-dev