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

[Brian Goetz]

> 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.