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

[Luke Hutchison]

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.