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

[Remi Forax]

----- Mail original -----
> De: "Mike Hearn" 
> À: "jdk-dev" 
> Envoyé: Vendredi 11 Octobre 2019 14:45:20
> Objet: Please stop incrementing the classfile version number when there are no format changes

> Hello,

Hi Mike,

> 
> Since the new versioning strategy was introduced, the classfile format
> number increments with every release regardless of whether or not anything
> was actually added. The way the class format is versioned is proving
> disastrous for the community. Please consider a policy change to not
> increment the format unless there are actually new features added.
> 
> We are currently in the following situation:
> 
> Java 11 has serious regressions in SSL support that are fixed, but only in
> Java 13, and not backported in OpenJDK. So we have to use a vendor spin of
> Java 11 with these fixes backported.
> 
> We tried our app with Java 13 but discovered Gradle doesn't work, so we
> can't build it.

I've never done that with Gradle but when compiling you should be able to ask for using an external javac so you can run Gradle with the jdk 11 and still use javac from the jdk 13 with the caveat that you need both jdk to be installed.

> 
> Gradle doesn't work because Groovy doesn't work.
> 
> Groovy doesn't work because it uses ASM and ASM rejects classfiles with the
> new format number. The Groovy fix is here:
> 
> https://github.com/apache/groovy/pull/887/files
> 
> There's no *actual* change needed - simply updating to a new ASM was
> sufficient to fix it.
> 
> ASM doesn't work because it doesn't know if anything important was changed
> in the new classfile version. But in Java 13 nothing actually changed and
> thus the ASM changes are also no-ops:
> 
> https://gitlab.ow2.org/asm/asm/commit/fc2fa0bedc9cd43680b758602149f433fc4c7948
> 
> Propagating this 1 character version number check change in ASM through the
> entire Java ecosystem dependency stack is a nightmarish task. Many
> libraries fat-jar ASM so you can't even just change it on the classpath to
> fix things ... many projects need to do new releases, and anything
> depending on them needs to do new releases and so on, recursively.
> 
> In practice this means Java 13 is ... just like its predecessors ...
> massively breaking and backwards incompatible for no good reason at all. We
> have no choice but to ignore it for a while until the new ASM propagates,
> by which time Java 14 will be out and the cycle repeats. I think we'll be
> paying vendors for Java 11 backports for a considerable length of time as a
> consequence.

hum, not necessarily, it depends if Java 14 includes records and sealed types or not.

> 
> Ideally the format version wouldn't be incremented unless a semantic change
> would cause old software to mis-interpret the new files without realising
> it. Many types of change e.g. new CP entry types look like they can be
> added without a version change, because if old software encountered them
> they'd throw some more precise kind of exception, and that would scope
> errors to only the files that actually used the new features instead of
> every file compiled by a new release.
> 
> Could this policy please be revisited? It's crushing the communities
> ability to upgrade.

Even if there is no classfile changes, you still can have JVM spec changes and JDK API changes, if you don't bump the version number, you don't now what are the API calls that are legal or not, so you can not do a static analysis to validate that there is no method call in a jar to a newer JDK API. In this world you are proposing, you will have to trust not only javac but all applications that generates .class files.

regards,
Rémi