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.go...@oracle.com
<mailto:brian.go...@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.
