On Thu, 16 Feb 2023 11:00:48 GMT, Maurizio Cimadamore <mcimadam...@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
