POC: JDK ClassModel -> ASM ClassReader

[Remi Forax]

----- Original Message -----
> From: "Ben Evans" <benjamin.john.evans at gmail.com>
> To: "Paul Sandoz" <paul.sandoz at oracle.com>
> Cc: "Rafael Winterhalter" <rafael.wth at gmail.com>, "Brian Goetz" <brian.goetz at oracle.com>, "classfile-api-dev"
> <classfile-api-dev at openjdk.org>
> Sent: Tuesday, July 19, 2022 12:56:05 PM
> Subject: Re: POC: JDK ClassModel -> ASM ClassReader

Hi Ben,

> 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.
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.
So i do not think that ASM using the JDK as backend will change something.

Also Gradle was a usual suspect and recently they have updated gradle to work even with older ASM version by disabling the incremental compilation.

> 
> Thanks,
> 
> Ben

Rémi