POC: JDK ClassModel -> ASM ClassReader

[Ben Evans]

On Wed, Jul 20, 2022 at 8:08 AM <ebruneton at free.fr> wrote:
>
> Le 19/07/2022 20:37, Ben Evans a écrit :
> > What worries me is that:
> >
> > a) The Classfile API ends up not containing everything that is really
> > needed by library authors, so they don't switch
>
> I don't think a rewrite of ASM on top of ClassFile is necessary for
> that. The work that Rafael is doing should be very helpful already. As
> well as all the feedback you receive on this mailing list.

I think that you're absolutely right in that Rafael's input will be
invaluable, but my take is that having 2 or more points of view from
library authors would be even better.

And - to be completely explicit, I'm not actively working on this (I
wish I had the time, but I'm fully committed elsewhere) - I'm only
trying to provide some feedback as a former tool maker who was a
consumer of ASM and who has seen first hand some of the problems that
the status quo has caused for customers, and who can see real
potential for the Classfile API to solve some of those problems, if we
can find the right path forward.

> > c) Even if a) turns out not to be a problem, the time to get enough of
> > the ecosystem moved over to Classfile API is potentially extremely
> > long.
>
>  From these 3 points it seems that your goal is for the ClassFile API to
> eventually replace ASM? Yet this is listed as a non goal in
> https://bugs.openjdk.org/browse/JDK-8280389? Can you clarify?

That's better directed at the Oracle folks. I read it as "within the
context of this JEP, which does not include a public API". I think
it's naive to assume that as and when a public API exists, that people
won't use it / won't seek to remove usage of third-party bytecode
libraries.

> About the "majority of cases" where the class file format does not
> change between two JDK versions, why is the class file version still
> incremented? If it was not, this would solve several cases where tools
> such as ASM must be "updated" for no real reason. Another option would
> be to increment the minor version only, and to reserve major version
> increments for real format changes. If this was added to the JVMS, tools
> such as ASM could take advantage of this, and would need to be updated
> less often (in fact I realize that ASM is already checking the major
> version only, so we unconsciously already assumed that minor version
> changes are not important).

That's one for the Oracle folks. Personally, I can see both sides of
that argument & feel like either choice would have been a reasonable
outcome - but that is strictly my own personal feeling.

Thanks,

Ben