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

forax at univ-mlv.fr forax at univ-mlv.fr
Fri Oct 11 20:48:30 UTC 2019

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

More information about the jdk-dev mailing list