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

Luke Hutchison luke.hutch at gmail.com
Mon Oct 14 20:00:16 UTC 2019

On Mon, Oct 14, 2019 at 1:55 PM Luke Hutchison <luke.hutch at gmail.com> wrote:

We're coming up on 24 years since Java's initial 1.0 release. So three breakages in 24 years that would break any scanner (like ClassGraph) that ignores the classfile version number averages out to one breakage (due to constant pool changes) every 8 years. (I previously asserted this might happen once every 10 years.) But 24 years from now, assuming the 6 month cadence continues, any library that simply throws an exception when it encounters a new classfile version number (as Brian has suggested is the only reasonable thing to do) leads to one breakage every 6 months, or (24 * 2 + 1) = 45 breakages over the same period. What Brian has proposed would lead to breakage 45 / 8 = 5.625x as often on average. So you'd be "out of business" 5.625x faster if you followed this suggestion and simply balked at new version numbers.

Oops, correction to my math! 45 breakages per 24 years divided by 3 breakages per 24 years is of course 15x faster, not 5.625x faster -- it's even worse than I claimed.

More information about the jdk-dev mailing list