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

Cédric Champeau cedric.champeau at
Sun Oct 13 14:59:08 UTC 2019

Hi folks,

I want to amend my answer because it appears, after I checked, I said
something wrong (I should have checked before answering, my memory isn't
that great). We use ASM for different use cases, that I sorted from least
problematic to most problematic:

1. Runtime decoration of classes. Gradle generates classes from definitions
of interfaces, adds missing methods for backwards compatibility, etc... No
issue in this case because all runtime decoration is done for classes of
Gradle itself or plugins. It's only a problem if the plugin itself uses
classes from an unrecognized JDK, which means the plugin would target
latest and greatest JDK, which is extremely unlikely because in general you
want your plugin to target the same version of JDK as Gradle runtime itself
(which is 8 today)
2. Compile avoidance. For each compilation task, we "snapshot" the inputs
and compute a hash of the public API of each element on the compile
classpath. If, for example, the public API of an upstream dependency hasn't
change, we know we don't have to recompile things. For this, if, for some
reason, we cannot compute the hash (because for example ASM barfs on the
the class version), we *do fallback to good old, byte hashing*, which means
that compile avoidance is effectively disabled, but Gradle works.
3. Incremental compilation. For each compiled class, we analyze its
dependencies, so that we know that if one of them changed we need to
recompile this or that class. If ASM doesn't recognize the class version,
we fail the analysis. Workaround: disable incremental compilation (easy)
4. Groovy scripts. This is the most problematic because Groovy depends on
ASM, and we have to be pretty conservative on Groovy updates because there
have been quite a few regressions lately. So basically, we have to choose
between breaking some user builds or supporting the latest JDK for Groovy
script users. Workaround: use the Kotlin DSL instead.

So, all in all, Gradle is quite compatible with the latest JDK even if not
officially said so. For example, I'm totally able to build a library using
JDK 13 and Gradle 5.6.2:

This puts a bit more perspective on things, there's a lot of FUD around
this ;)

Le sam. 12 oct. 2019 à 18:47, Alan Bateman <Alan.Bateman at> a
écrit :

> On 12/10/2019 13:07, Mike Hearn wrote:
> > :
> >
> > Finally, there's a more general observation to make on backwards
> > compatibility. In the 1990s Microsoft became famous for bending over
> > backwards to keep running code, even if it was buggy or totally
> > unreasonable. With the internet this intensity slackened because
> > vendors could release new versions to users, but only a little bit -
> > companies go bankrupt and projects become unmaintained. Java today is
> > backwards compatible in theory but not in practice. Every release
> > breaks something, often something fundamental like our build systems.
> > If OpenJDK is serious about wanting users to upgrade every six months
> > then the backwards compatibility philosophy will need to change to be
> > like Microsoft's: remove the constructor /after/ Groovy accepted a
> > patch to stop using it, not before.
> I don't know if you have the full context here or not. This is not about
> removing a constructor from the API, instead the change was to the
> signature of a private constructor. It's way too fragile to have
> important tools or libraries hacking into private fields or other
> members and expecting them to work from release to release (even build
> to build!). Also remember that the JDK has been emitting warnings at
> run-time since JDK 9 to help identify code like this.
> On your more general point then it would be very unfair to suggest that
> that there isn't a culture of compatibility in this project. The effort
> that goes into maintaining compatibility is incredible to observe at
> times. Every major feature has to painstakingly work through the
> implications on every other part of "the system". Small changes too
> where experienced committers and reviewers need to take compatibility
> into account when reviewing a change. Then there is the Compatibility &
> Specification Review (CSR) group that is the review body to review all
> changes that have potential compatibility issues. Despite the heroic
> efforts there will be bugs and compatibility issues that slip through.
> This is where this project depends on a larger cohort of developers to
> help by trying out their libraries, tools, and other existing code to
> find issues, ideally long before GA. In the case of TLS 1.3 (which was a
> massive project, several person years of effort, several supporting
> JEPs) there was great help on security-dev from several projects and
> individuals and many bugs were reported and fixed. Somehow we need to
> dial up this participation a hundredfold and catch more issues before
> GA, not after GA. I think it will only work if the maintainers of all
> the main stream tools and libraries are willing to get involved and not
> wait for a release to GA before adding support.
> -Alan

More information about the jdk-dev mailing list