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

[Maurizio Cimadamore]

On 11/10/2019 21:51, Luke Hutchison wrote:
> 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

I'm not fully convinced by this line of reasoning. Since you bring up 
CONSTANT_dynamic, here's a path that we *could* have taken (but that 
wasn't taken): condy gives a better way to translate non-capturing 
lambdas (using a condy instead of an indy). In principle we could have 
added both the condy support _and_ the javac support to start 
translating non-capturing lambdas using condy instead of indy. If we did 
that, I think this situation shows some weakness in your argument about 
ignoring the bits of a classfile a client doesn't understand; what 
exactly does it mean to pass a class that contains newly condy-compiled 
lambdas on a tool that doesn't understand them? Let's say the tool in 
question is a code coverage tool, or some static checker of sort; would 
it be really considered an acceptable to have this tool skip over most 
of the lambda expressions in the user code? I mean, yes, the tool would 
_run_ w/o crashing, but that's pretty much all you can say about it.

In other words, yes, classfile N+1 might be a superset of classfile N, 
but as the features in N+1 are used pervasively in N+1 classfiles, 
there's not much that N-compatible tools might realistically do with N+1 
classfiles. Of course there will be cases where you might have more 
luck, but in the general case I don't see this flying.

I think a crucial point was hit earlier in this discussion; nearly every 
complex piece of software out there relies on some classfile library; if 
classfile version is updated often, classfile libraries must also be 
updates often (as ASM does, thanks Remi). Which means that _all_ 
software artifacts that depend on classfile libraries must also be 
updates as often, or they risk being left behind. Which seems to suggest 
that, if _some_ bytecode library was bundled in the JDK, as noted 
earlier in this thread, the problem described here would be mostly 
non-existent. As Brian said, this is a need that we anticipated coming, 
and we hope to do something in this space.

Maurizio