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

Maurizio Cimadamore maurizio.cimadamore at oracle.com
Fri Oct 11 23:12:21 UTC 2019

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

More information about the jdk-dev mailing list