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

Remi Forax forax at
Fri Oct 11 19:12:43 UTC 2019

ASM is fully backward compatible since ASM4,
so you can take the version of Gradle compatible with Java 12, remove the ASM jar and replace it with the newer version,
if there is no other checks in Gradle, it will work.


----- Mail original -----
> De: "Mike Hearn" <mike at>
> À: "Brian Goetz" <brian.goetz at>
> Cc: "jdk-dev" <jdk-dev at>
> Envoyé: Vendredi 11 Octobre 2019 20:23:28
> Objet: Re: Please stop incrementing the classfile version number when there are no format changes

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

More information about the jdk-dev mailing list