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

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