POC: JDK ClassModel -> ASM ClassReader

[ebruneton at free.fr]

Hi Ben,

Le 19/07/2022 15:07, Ben Evans a écrit :
> 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).

Forward compatibility is a difficult topic I think, even for the 
ClassFile API. I don't think users will be able to just upgrade to the 
latest JDK to have their ClassFile API code automatically work with the 
latest class version. In the majority of cases, maybe. But there will be 
cases where their code might silently fail, when the new class version 
introduces new features.

For example, consider the ClassRemapper here 
https://github.com/openjdk/jdk-sandbox/blob/classfile-api-branch/src/java.base/share/classes/jdk/classfile/transforms/ClassRemapper.java. 
It seems that it currently does not remap record components, annotations 
or type annotations, modules, LDC opcode, etc? You could imagine that it 
was written for an old class version, pre annotations. If you upgrade to 
a new JDK version with records and type annotations, this code will 
silently produce incorrect results, where not everything is remapped. It 
might be possible to rewrite it in a more secure way, but this would 
probably require all "switch" to list all known options at the time of 
writing (and the default case to throw an exception)?

If your code has a dependency to such a library, you will be stuck to 
old JDK versions as long as the library's author does not update it to 
support the new features. Whatever the class file API it uses (ASM, 
ClassFile, etc).

ASM has a "max recognized version" in ClassReader and an ASM API version 
provided by user code (which declares for which ASM API version it was 
written), in order to address these forward compatibility issues (they 
are discussed in more details p82 of https://asm.ow2.io/asm4-guide.pdf). 
The goal is that user code should not silently fail because of new class 
file features.

What kind of forward compatibility guarantees do you want to provide 
with the ClassFile API? Are they or will they be documented somewhere? 
Will there be recommendations for users so that their code does not 
silently fail in case of new class features? Or can this guarantee be 
ensured by the API somehow?

About the future of ASM, I would say we will continue to support users 
who need it. If at some point most users have switched to the ClassFile 
API, we can deprecate it. For the reasons explained above, I don't think 
that refactoring ASM as a thin layer on top of the ClassFile API would 
bring any benefit.

Eric

> Thanks,
> 
> Ben