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

[Luke Hutchison]

On Fri, Oct 11, 2019 at 2:10 PM Mike Hearn <mike at plan99.net> wrote:

> I didn't completely follow the rationale for gating everything behind a
> version number though. Whether it's new bytecodes or new CP entry types, it
> seems like classfile parsing libraries should be able to throw exceptions
> on encountering the most common kinds of new features quite reliably.
>

As a maintainer of a fairly widely used classfile format parsing library,
it's a bit pesky to have to push out a new release of an otherwise very
stable library every 6 months just because the JDK bumped the classfile
format number, usually without any changes that affect the classfile
parsing library in any way. If a classfile parsing library threw an
exception every time a classfile was encountered that had been generated by
a newer JDK release, even if the file could be parsed perfectly well, it
would bother a lot of users. Also consider that throwing an exception for a
new classfile release number would mean as soon as a user started using an
"-ea" release, they would get exceptions in major classfile parsing
libraries based on classfile version number alone, because these libraries
are unlikely to keep up to date with unreleased JDK versions, let alone
each new released version.

I decided a couple of years ago that ClassGraph should ignore the format
number entirely, and simply parse what could be parsed, ignoring what was
unknown but could be skipped over, and throwing an exception only when a
record of unknown length was encountered. This has worked very well in
practice. (Admittedly ClassGraph doesn't do anything with actual bytecodes
currently, so this approach would not work as well for something like ASM,
although if new opcodes also had length info stored in classfile metadata,
even ASM could work with bytecodes containing unknown future operator
types, even if it couldn't understand what those opcodes did.)