Please stop incrementing the classfile version number when there are no format changes
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