Please stop incrementing the classfile version number when there are no format changes (original) (raw)

Cédric Champeau cedric.champeau at gmail.com
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: https://scans.gradle.com/s/2fydeffe5yida

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 oracle.com> 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