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

Brian Goetz brian.goetz at oracle.com
Fri Oct 11 13:48:04 UTC 2019

Since the new versioning strategy was introduced, the classfile format number increments with every release

Actually, this policy dates back basically to the dawn of time. It has nothing to do with the new versioning scheme; it has always been this way. See: https://en.wikipedia.org/wiki/Java_class_file#General_layout <https://en.wikipedia.org/wiki/Java_class_file#General_layout> (table entry on major versions.)

regardless of whether or not anything was actually added.

“Was something added” was never the criteria for bumping the class file version. You think you’re asking that a recent policy be reconsidered, but in fact, you’re asking for us to throw out the policy that has served us well for 25 years. While I would not say it is impossible that there might be a valid reason to reconsider, let’s not pretend you’re not asking for a radical change in policy.

Further, the often-repeated “but nothing changed” argument is generally based on a misunderstanding of what “changed” means. There are many, many more ways to have a version dependency besides “new byte codes”, such as new constant pool forms (e.g., candy), new class file attributes (e.g., NestMembers, PermittedSubtypes), or dependency of compiler-generated code on a library class or method entry point (such as Iterable, Enum, or indy bootstraps). Given the likely-ubiquity of such translation dependencies in almost every future version, it is unlikely that such a policy change would likely reduce the frequency of classfile-bumps by very much — but would still have users guessing why (say) the 13 to 14 transition has different characteristics than 14 to 15.

Further^2, I think you underestimate the cost of late-binding to a class file version bump, and the effect it would have on forward platform progress. This is not, as most developers seem to reflexively assume, a mere bureaucratic mandate; this is a policy driven by engineering reality.

The way the class format is versioned is proving disastrous for the community.

Again, you’re acting like this is a new thing. Given that we’ve been doing it this way for nearly 25 years, it can’t be all that disastrous.

More information about the jdk-dev mailing list