RFR: 8334714: Implement JEP 484: Class-File API [v9]
Chen Liang
liach at openjdk.org
Mon Dec 9 18:42:53 UTC 2024
On Fri, 15 Nov 2024 11:53:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:
>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>>
>> Please review.
>>
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>
> - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>
> # Conflicts:
> # src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
> - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
> - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>
> # Conflicts:
> # src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
> - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>
> # Conflicts:
> # src/java.base/share/classes/java/lang/classfile/AccessFlags.java
> # src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
> # src/java.base/share/classes/java/lang/classfile/ClassElement.java
> # src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
> # src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
> # src/java.base/share/classes/java/lang/classfile/ClassModel.java
> # src/java.base/share/classes/java/lang/classfile/ClassReader.java
> # src/java.base/share/classes/java/lang/classfile/ClassSignature.java
> # src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
> # src/java.base/share/classes/java/lang/classfile/CodeElement.java
> # src/java.base/share/classes/java/lang/classfile/CodeModel.java
> # src/java.base/share/classes/java/lang/classfile/CompoundElement.java
> # src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
> # src/java.base/share/classes/java/lang/classfile/FieldElement.java
> # src/java.base/share/classes/java/lang/classfile/Instruction.java
> # src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
> # src/java.base/share/classes/java/lang/classfile/MethodElement.java
> # src/java.base/share/classes/java/lang/classfile/TypeKind.java
> # src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
> # src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
> # src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
> # src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
> # src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
> # src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynami...
I fear that promoting creation of unbound `PoolEntry` may be a bad move - they are there only for temporary components of attributes. We should promote creating a local pool entry whenever possible - this is one of the tricks for CodeBuilder optimization, where the usage of CodeBuilder convenience factories elide the creation of intermediate instruction and non-local pool entry objects.
Also for `TemporaryConstantPool` - it has a few weird behaviors, especially that its elements have bad indices. The `TemporaryConstantPool` itself is never used as a `ConstantPoolBuilder`, and it can be refitted to only implement `ConstantPool` with minimal impact. (Well, aside from these blunt cast-and use cases you've shown)
-------------
PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2529060857
More information about the compiler-dev
mailing list