POC: JDK ClassModel -> ASM ClassReader

[Ben Evans]

On Tue, Jul 19, 2022 at 2:52 PM Remi Forax <forax at univ-mlv.fr> wrote:
>
> > From: "Ben Evans" <benjamin.john.evans at gmail.com>
>
> > On Mon, Jul 18, 2022 at 10:31 PM Paul Sandoz <paul.sandoz at oracle.com> wrote:
> >>
> >> Fair point. How might you envisage the future of ASM? some stripped down version
> >> with integration hooks into the classfile API?
> >
> > If this approach was adopted by the ASM folks it would potentially
> > remove a barrier to adoption of non-LTS JDK versions in production.
> >
> > Specifically, it removes the risk of being stuck on an orphaned JDK
> > version because the current JDK version is not supported by the ASM
> > version that one of your key dependencies is pinned to.
> >
> > If ASM becomes a wrapper & value-add over the JDK Classfile API then
> > "maximum supported JDK version" is a property solely of the JDK, not
> > of the ASM library, and so is no longer a barrier to upgrading the
> > JDK.
> >
> > I'm sure it's not the not only barrier to getting more people to use
> > non-LTS in production, but based on what I saw at New Relic (where
> > customers raised this issue, or its consequences, fairly regularly) I
> > think it could be a significant one.
>
> ASM is fully backward compatible for *every* releases of the JDK, LTS or not.

Backward compatibility is not the issue here - we're talking about
*forward* compatibility.

> Usually, ASM is not directly the issue, the issue is some libraries that are using an older version of ASM and users not wanting to update solely ASM.

That's exactly what I said above:

> > it removes the risk of being stuck on an orphaned JDK
> > version because the current JDK version is not supported by the ASM
> > version that one of your key dependencies is pinned to.

> So i do not think that ASM using the JDK as backend will change something.

Why not? If the "maximum supported JDK version" constant comes from
the JDK, not from ASM, then upgrading the JDK (without touching ASM)
will also upgrade the max supported version that ASM can handle (in
the majority of cases, i.e. that don't touch any aspect of bytecode
that might have been altered in the new JDK version).

Thanks,

Ben