RFR: Classfile API ClassRemapper implemenation handling more attributes

[Adam Sotona]

Hi,
I’ve implemented handling of RecordAttribute, InnerClassesAttribute, EnclosingMethodAttribute, Annotations, TypeAnnotations, ParameterAnnotations attributes and LoadableConstants in ClassRemapper.
Please review: https://github.com/openjdk/jdk-sandbox/pull/27

Thanks,
Adam


From: classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf of Adam Sotona <adam.sotona at oracle.com>
Date: Wednesday, 20 July 2022 10:05
To: ebruneton at free.fr <ebruneton at free.fr>, Ben Evans <benjamin.john.evans at gmail.com>
Cc: Remi Forax <forax at univ-mlv.fr>, Paul Sandoz <paul.sandoz at oracle.com>, Rafael Winterhalter <rafael.wth at gmail.com>, Brian Goetz <brian.goetz at oracle.com>, classfile-api-dev <classfile-api-dev at openjdk.org>, classfile-api-dev <classfile-api-dev-retn at openjdk.org>
Subject: Re: POC: JDK ClassModel -> ASM ClassReader


From: classfile-api-dev <classfile-api-dev-retn at openjdk.org> on behalf of ebruneton at free.fr <ebruneton at free.fr>
Date: Tuesday, 19 July 2022 19:27
To: Ben Evans <benjamin.john.evans at gmail.com>
Cc: Remi Forax <forax at univ-mlv.fr>, Paul Sandoz <paul.sandoz at oracle.com>, Rafael Winterhalter <rafael.wth at gmail.com>, Brian Goetz <brian.goetz at oracle.com>, classfile-api-dev <classfile-api-dev at openjdk.org>, classfile-api-dev <classfile-api-dev-retn at openjdk.org>
Subject: Re: POC: JDK ClassModel -> ASM ClassReader

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)?

Hi Eric,
Thanks for pointing ClassRemapper out. It was written as an example of transformations modularity for jdk.jfr class instrumentation use case.
The implementation is incomplete yet, however I see no blockers to finish it and keep it up to date with every new JDK feature coming.

Thanks,
Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20220720/d8a6ee4c/attachment-0001.htm>