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

Luke Hutchison luke.hutch at gmail.com
Sat Oct 12 03:56:36 UTC 2019

On Fri, Oct 11, 2019 at 5:12 PM Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote:

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.

I agree that "strong" static analyzers (code verifiers etc.) should always be able to understand the entire classfile, or reject unknown version numbers, even simply for security reasons alone. And anything that deals with bytecodes falls out of the scope of the issues I am raising. There are many tools that never need to parse bytecodes, but do need class metadata. and I (still) think it is entirely reasonable for these tools to parse only the backwards-compatible subset of a classfile that they are able to understand.

Of course, if there is a major break in classfile format, class metadata parsers will need to upgrade their parsing logic! That goes without saying, and as I said previously, I would never debate that it is the libraries' responsibility to deal with those situations. But based on the entire history of the classfile format to this point, and extrapolating into the future, that is quite arguably going to be a very rare occurrence.

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.

If you're ASM, it doesn't fly. If you're one of dozens and dozens of class metadata files, a best-effort attempt to parse a classfile in a way that doesn't break when a new JDK comes out is more than fine for 99.9+% of usecases.

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

On the "as ASM does, thanks Remi" comment -- off the top of my head, if it had existed since a long time ago, ClassGraph would have needed only one major update in the last 22 years to handle major additions to the classfile format, not counting additional constant pool types (which have been added a few times, such as the changes I mentioned with JDK 9), specifically the addition of generic type signatures with JDK 1.5 (and this is optional information anyway, it just gives the parsed methods and fields richer type information). Of course I plan to update ClassGraph whenever there is a major change, in fact ClassGraph keeps the bug count and feature request at zero through a "Zero Bugs Policy", and most bugs are fixed and releases pushed out within 24 hours. The turnaround time of ClassGraph vs. ASM is not the point.

The point is that you cannot expect the whole Java ecosystem to update all their transitive dependencies for any library, whether it be ASM or ClassGraph or Reflections or anything else, every 6 months. And once you start monkeypatching your Maven POM files to forcibly override old versions of indirect dependencies, every time a new classfile format is released (as Remi and I discussed previously), you can start getting into dependency hell quickly.

Which means that all software artifacts that depend on classfile libraries must also be updates as often, or they risk being left behind.

Yes, this exactly.

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.

I would be very happy if nobody ever needed ClassGraph or ASM or anything like it, because the JDK had a rich enough metaprogramming model to obsolete all these things.

More information about the jdk-dev mailing list