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

Mike Hearn mike at
Fri Oct 11 12:45:20 UTC 2019


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.

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:

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:

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

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.

More information about the jdk-dev mailing list