POC: JDK ClassModel -> ASM ClassReader
ebruneton at free.fr
ebruneton at free.fr
Tue Jul 19 17:27:27 UTC 2022
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
More information about the classfile-api-dev
mailing list