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

[Alan Bateman]

On 11/10/2019 15:15, Cédric Champeau wrote:
> - Gradle performs bytecode analysis, to extract the public API of compiled
> classes and allow _compile avoidance_ (avoid recompiling downstream
> dependencies if nothing changed in the public API). For this, we use ASM
> too, and every change in the class format forces us to upgrade ASM. This is
> the most problematic bit, because even if you fork compilation, we can't
> analyze the generated class files (because it's done in the snapshotting
> phase which is in the Gradle process itself).
The most valuable way for developers to contribute to OpenJDK is to try 
out builds of the main line to find issues and provide feedback on 
recently added features/changes. That is really hard to do if the main 
stream tools aren't working with the latest JDK bits. All the recent 
developer surveys that I've seen suggest that Gradle is used by about 
20% of developers or projects. That is potential trouble for one in five 
developers that are want to contribute by trying out the JDK early 
access builds. Is there any way to get Gradle to align with the 
predictable releases of OpenJDK so that developers can use Gradle with 
JDK EA builds? The discussion here has been about JDK 13 but we are 
already several months into the JDK 14 release. JDK 14 will be more 
challenging for Gradle because there are changes that expose a bug in 
Groovy where it hacks a non-public constructor that no longer exists 
[1][2]. It appears this has been resolved for Groovy release that is 
currently in beta (great!) but it's not clear if developers on the 
bleeding edge can get a working tool chain. I don't know what Gradle's 
priorities are but I think it would be wonderful if there were Gradle 
downloads that tracked the main line and a GA release at or around the 
time that the JDK releases so that developers always have working tool 
chain.

-Alan

[1] https://issues.apache.org/jira/browse/GROOVY-9211
[2] https://github.com/gradle/gradle/issues/10248