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

[Mike Hearn]

Point taken about writing a JEP.

Remi: By "bundle ASM" I didn't mean literally, but like what was done for
Joda Time → java.time. So yes, a JEP to develop a stable bytecode spinning
or transformation API would be good. ASM is clearly a good fit for people's
needs so it'd have to be the starting point, but nothing would stop users
continuing to use the original ASM if they for some reason needed to run on
Java 5 :)

Fortunately for our project, Alexey Shipilev followed up with me off-list
to ask about the SSL regressions. It seems some of the bugs weren't being
backported just through being overlooked, or we'd been told they weren't
backported and they were. I guess we're still learning the vendor-backports
ropes. It sounds like 11.0.6 will now fix all the bugs we encountered and
so we'll be able to jump to 11 and stay there a while. We'd like to keep up
with regular Java upgrades of course, but I think the bytecode version
issue would need to be fixed before that'd be cheap enough to consider.

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.




On Fri, Oct 11, 2019 at 21:58:59, John Rose <john.r.rose at oracle.com> wrote:

> On Oct 11, 2019, at 12:39 PM, Remi Forax <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.)
>