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

Brian Goetz brian.goetz at
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: <> (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