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

Mike Hearn mike at plan99.net
Mon Oct 14 19:26:13 UTC 2019


Brian, I don't think that's an accurate or especially charitable view of
what people are arguing :(

The way I started this discussion was by saying:

Ideally the format version wouldn't be incremented unless a semantic change
would cause old software to mis-interpret the new files without realising
it.


That's not the same as arguing it's *always* safe to parse data from the
future. Perhaps you're referring to Luke's request for length prefixing CP
entries. Even there the issue is not one of naivety, which isn't a hugely
helpful adjective, but a different tolerance for risk/effort tradeoffs. For
any given change it will be safe for many programs to ignore it. I think
Luke is simply arguing that many developers would find it preferable to
take the bug report for an exception or even a wrong result (!) in the case
of a genuine loss of forwards compatibility that affects them, than have
software reliably stop working on schedule 'just in case'. ClassGraph is
commonly used just to locate classes that have an annotation on them after
all, and as far as a I know all planned format changes would still allow
this task to be done. Yes, people might annotate new class-like-things such
as values and confuse old ClassGraphs; that's an ordinary sort of bug and
the JVM shouldn't impose large costs on the entire ecosystem to try and
avoid the occasional edge case of "a new class-like entity in files that
end in .class but aren't that close really".

On costs, there's clearly a key difference of intuition here. You said that
the "few" should not hold back the "99.9999%". My intuition (and I think
that of quite a few posters on this thread) is that the real situation is
the reverse - *most* of the Java ecosystem is ignoring the faster release
cycle. It's in the process of going straight from Java 8 to Java 11 and is
now coming to rest there for a while. From this vantage point it seems like
hardly anyone upgrades every six months; perhaps the selection of Java
apps/libraries I use is biased, but I'm generally surprised when I see
something advertise Java 12/13 support. It's tough to find bugs in EA
releases if it takes six months for your app's dependencies to catch up.

Everyone wants the same thing here - we'd love to be able to set up a cron
job and upgrade Java every few weeks to test the latest EA releases or get
the latest improvements. We're making suggestions in that spirit. For
instance, another idea worth exploring might be target versioning: Android
and iOS both use this, and Android has successfully provided a massive
level of backwards compatibility for over a decade in a Java-based
environment using it. It might be useful to experiment with. But if you'd
rather not have people propose ideas for what would make their upgrades
easier, well, that seems like a pity.


More information about the jdk-dev mailing list