RFR: 8294982: Implementation of Classfile API [v20]

[Maurizio Cimadamore]

On Fri, 17 Feb 2023 09:20:21 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> 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.

Not sure I get this. It seems to me that the same attributes are being printed twice. But, perhaps, the first pass only creates a list with the attribute _names_ and then there is a later pass which print the attributes in full?

>> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 649:
>> 
>>> 647:             if (parentMap == null)
>>> 648:                 parentMap = new IdentityHashMap<>();
>>> 649:             int[] table = parentMap.computeIfAbsent(parent, new Function<CodeAttribute, int[]>() {
>> 
>> Can use a lambda here?
>
> I'll have to add relevant comment here.
> There are many places in the Classfile API, which are on critical JDK bootstrap path in the follow-up integrations and using lambdas or method references would cause stack overflow during JDK bootstrap.
> Using other words - these fragments cannot use lambdas as they suppose to generate lambdas for JDK ;)

I suspect that was the case :-)

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

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