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

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