On Fri, 17 Feb 2023 09:20:21 GMT, Adam Sotona <asot...@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
