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

[forax at univ-mlv.fr]

> De: "John Rose" <john.r.rose at oracle.com>
> À: "Remi Forax" <forax at univ-mlv.fr>
> Cc: "Mike Hearn" <mike at plan99.net>, "jdk-dev" <jdk-dev at openjdk.java.net>
> Envoyé: Vendredi 11 Octobre 2019 21:58:59
> Objet: Re: Please stop incrementing the classfile version number when there are
> no format changes

> On Oct 11, 2019, at 12:39 PM, Remi Forax < [ mailto:forax at univ-mlv.fr |
> forax at univ-mlv.fr ] > wrote:

>>> P.S. Mike your point about a bundled ASM is a very good one.
>>> The lack of a bytecode spinner in the JDK is long-standing tech. debt,
>>> on which the interest rate has risen (because the payments are the
>>> same but now come due every six months). Who’s on the hook to
>>> fix this? All of us, really; it’s the OpenJDK. Starting up a JEP would
>>> make a good place to gather information about options and requirements.

>>> — John

>> The problem of bundling it in the JDK is that it forces people that maintains
>> libraries that want to read/write the newest classfiles to be compatible with
>> the newest JDK unlike ASM which only requires Java 5.
>> So it will solve the problem of Mike but will cause problems to others that have
>> not yet migrated their libraries to the newest JDK.

> Yep. This is the sort of observation that we’ll want to accumulate around a JEP.

> (BTW, I didn’t say “lack of ASM” I said “lack of a bytecode spinner”, in JDK.
> And putting one in wouldn’t be a cure-all either. There are advantages to having
> ASM decoupled from the JDK, as well as disadvantages.)

I don't disagree :) 
and you need a little more than a spinner because you also need to be able to parse the module-info.class for the module API. 

Rémi