RFR: 8294982: Implementation of Classfile API [v20]

[Adam Sotona]

On Thu, 16 Feb 2023 11:00:48 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   added 4-byte Unicode text to Utf8EntryTest
>
> src/java.base/share/classes/jdk/internal/classfile/impl/ClassPrinterImpl.java line 563:
> 
>> 561:                       list("attributes", "attribute", clm.attributes().stream().map(Attribute::attributeName)))
>> 562:                 .with(constantPoolToTree(clm.constantPool(), verbosity))
>> 563:                 .with(attributesToTree(clm.attributes(), verbosity))
> 
> Is this ok? It seems we also add class attributes in the map node (see "attributes" map node).

Yes, the print structure does not exactly correspond to the Classfile API architecture, but rather to the classfile physical structure and it is partly similar to `javap` output.
The common tree structure has been reverse-designed from the desired visual representations in all supported text formats and in all verbosity levels.

> src/java.base/share/classes/jdk/internal/classfile/impl/SplitConstantPool.java line 83:
> 
>> 81:  * ConstantPool.
>> 82:  */
>> 83: public final class SplitConstantPool implements ConstantPoolBuilder {
> 
> Not sure the "Split" prefix carries any meaning? (perhaps a leftover from previous iterations?)

The "Split" represent a division between the original read-only constant pool and the new part with additional CP entries.

> src/java.base/share/classes/jdk/internal/classfile/impl/TemporaryConstantPool.java line 60:
> 
>> 58:     private static final Options options = new Options(Collections.emptyList());
>> 59: 
>> 60:     private TemporaryConstantPool() {};
> 
> If I understand correctly, this constant pool is just "fake" in the sense that it's a builder which creates constant pool entries w/o storing them anywhere. This seems to be used in places where e.g. we need to convert a ClassDesc to a ClassEntry, probably so that the implementation of e.g. attributes can be defined in terms of constant pool entries, even when "unbounded". E.g. this is a trick which avoids having completely different representations for bound and unbound elements - correct?

Yes, exactly :)

-------------

PR: https://git.openjdk.org/jdk/pull/10982