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

Brian Goetz brian.goetz at oracle.com
Fri Oct 11 21:11:03 UTC 2019

I think you are arguing in the abstract simply because of what is possible, but not at all because of what is remotely likely. Sure, I accept your point, but in practice, the classfile format has been almost a strict set of growing supersets, going all the way back to JDK 1.1, right? And there is a good reason for that, because Java has always cared a lot about backwards compatibility.

Actually, this sort of change is virtually guaranteed in the next five years, when we get to specializable generics in Valhalla.  I would really, really like to kill the misassumption that "the classfile will always remain backward compatible" earlier rather than later, so when we pull this trigger -- and we absolutely will -- no one can reasonably claim surprise.  The version number is the gate, and always has been.  Parsing classfile whose version you do not recognize is entirely a leap of faith, and someday you're going to fall on your face.  Better off to stop leaping before that happens!

I understand you are thinking "well, it's possible to define the classfile format in a way that is more self-describing, and then it would be easier, so isn't it obvious that we should just do that?" But, you're making the classic mistake of considering only the benefit, and not the cost.  For example, fatter classfile structures mean longer startup times for 100% of Java developers.  Should we really punish the 100% with worse startup for the sake of the .00001% of those who are maintaining bytecode-parsing tools, but aren't committed to keeping up? That seems like putting the burden in the wrong place.

OK, again I accept your general point, but I think you are arguing from an ideological point of view without acknowledging the benefit of fixing the issue I raised. There are ways to accomplish what I suggested (yes, making the format more self-describing) that incur close to zero extra cost. For example, I suggested adding a length field to every constant pool entry. But instead, there could be some simple metadata before the constant pool that gave the size for any new introduced constant pool types. Total cost: a few bytes per classfile. Total benefit: preventing much disruption for many users.

Except that would be the sort of incompatible change that this entire argument presupposes will never happen -- every classfile parser ever written assumes that the CP starts right after the version.  Also, it's not simply a matter of a table that says "constant #19 is three bytes", because constant pool entries can be variably sized (though we do try to avoid this.)  A self-describing format would require a more complex grammar -- so now we'd be spending complexity budget as well as footprint budget.

But, when we get to the point where we're considering some incompatible change, then yes, it might be reasonable to consider other changes to the classfile format at the same time.

More information about the jdk-dev mailing list