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

John Rose john.r.rose at oracle.com
Fri Oct 11 19:06:20 UTC 2019

On Oct 11, 2019, at 11:23 AM, Mike Hearn <mike at plan99.net> wrote:

OK. I understand your point that the policy has in some sense not changed. But from the user's view the effect is quite different: during the Java 8 timeframe there were years of upgrades and bug fixes that didn't change the class file format and which were essentially drop-in. But now every six months of improvements/bugfixes does change it, so if something can't handle the new version that's a constant series of upgrade problems, rather than once every few years as before.

Yes, the pace of the release has changed, and that compresses engineering schedules that are tied to the releases, in the ways (sometimes awkward) that you describe. So the policy is the same, but it has somewhat different effects at the six-month cadence. The different effects are a mixed bag: The faster cadence affects projects that track every release. But IMO (I admit I’m biased) the highest order effect is a spectacularly good one: faster roll-out of improvements to the technology. This means the ecosystem will go faster in valuable ways, as well as awkward ones.

Another point: The design of the new cadence takes into account the fact that some customers will prefer to take their changes at a more moderate pace, similar to Java’s original irregular cadence at the 2-3 year time scale. These customers surely appreciate the existence of LTS (long term support) releases in the new scheme.

In fact, the new-style LTS releases are arguably better than the original irregular releases, since they are regular and can be planned for, long in advance. (The predictability also enables a market in which LTS vendors can work and get paid, which I think is very good for the Java ecosystem.)

This probably doesn’t help you, Mike, but I will also observe that there might be some library providers out there (not just end-users) who will want to concentrate on supporting LTS releases and ignore some or all of the six-month regular releases. For these library providers, the cadence of their dependencies and customers will be similar to the old Java cadence, and (better yet) a reliable one.

I admit there are a new sources of “impedance mismatch” in an ecosystem with two cadences (6-month and LTS). But the advantages of the new faster cadence are so strong that I think we just have to learn to deal with a two-cadence system. I suppose our customers will enjoy a reliable, predictable choice between the LTS and the current release.

Final point: Besides losing the old system’s unpredictability, we are also losing an old source of “impedance mismatch” between differently staged releases: Some of us remember having to backport new features to many old releases, in a world where every release was LTS, and retiring it was always a special new discussion, rather than a settled policy. The fact that LTS releases have a natural and predictable life-cycle means that, at any point, we should (I hope) be asking our engineers to do fewer miscellaneous backports. So, there are multiple reasons why our new two-cadence system is more friendly and rational than the old ad hoc (non-)system. Let’s keep on doing the work to fix the present system, rather than looking back to the good old days—which weren’t really that good.

HTH

— John

P.S. Mike your point about a bundled ASM is a very good one. The lack of a bytecode spinner in the JDK is long-standing tech. debt, on which the interest rate has risen (because the payments are the same but now come due every six months). Who’s on the hook to fix this? All of us, really; it’s the OpenJDK. Starting up a JEP would make a good place to gather information about options and requirements.

More information about the jdk-dev mailing list