Please stop incrementing the classfile version number when there are no format changes

Mike Hearn mike at
Fri Oct 11 18:23:28 UTC 2019

OK. I understand your point that the policy has in some sense not changed.
But from the user's view the effect is quite different: during the Java 8
timeframe there were years of upgrades and bug fixes that didn't change the
class file format and which were essentially drop-in. But now every six
months of improvements/bugfixes does change it, so if something can't
handle the new version that's a constant series of upgrade problems, rather
than once every few years as before.

As Cedric has noted (I should have mentioned this), Gradle isn't ready to
release  Java 13 compatibility because ASM is really a dependency of
Groovy, which in turn has rolled the new ASM into a general upgrade which
may have regressions. It wasn't released as a point release. And then
Gradle 6 is itself a new major release which may break builds because of
the removal of deprecated APIs and so on. This pattern is common -
supporting new versions of Java isn't treated like a security hotfix but
rather, as a feature to be released with all the others.

Also, this isn't unique to Gradle. We use Quasar, and we use ASM directly,
and I think we use other libraries that also incorporate ASM snapshots in
various ways, so we end up with ASM dependencies in quite a few places. All
of these have to be upgraded in sync to support Java 13.

So in theory Java 13 is backwards compatible with 12 and should be able to
run existing projects. But in practice, because of a single version assert
in ASM, it could be quite a while before we can actually upgrade and it
will require a lot of work to propagate the change up through the giant
dependency pyramid we sit on top of. Actually we still haven't managed to
ship Java 11 support in our project yet, as it took months of work by a
dedicated developer (it should be in our next release but of course, 11 is
already obsolete). I think many projects will be in similar situations;
bytecode manipulation/synthesis is just so widely used throughout the
ecosystem that any time it breaks it causes a big bubble in the upgrade

More information about the jdk-dev mailing list