Classfile API AttributedElement.Kind removal proposal

[Brian Goetz]

Just a little bit of history here.  We started writing this API before 
we had pattern support in the language, so we used the classic trick of 
having an enum constant per node type that could be switched over.  When 
patterns came along, we thought about removing them, but we were still a 
little diffident as we knew that the cost of switching over types was 
higher than switching over enums, and worried about 
performance-sensitive transformation code.

I wouldn't mind seeing a quick microbench comparing switching over 
bytecodes the two different ways, just to see if it still shows up on 
the profile.

On 2/7/2023 9:33 AM, Adam Sotona wrote:
>
> Hi,
>
> Based on discussion in the Classfile API PR: 
> https://github.com/openjdk/jdk/pull/10982#discussion_r1098601988
>
> I would like to propose removal of AttributedElement.Kind across all 
> Classfile API.
>
> The AttributedElement.Kind models Attributes “where applicable” and it 
> is a duplication of each Attribute extending ClassElement, 
> MethodElement, CodeElement, etc…
>
> Classfile API is not actively using the AttributedElement.Kind except 
> for parsing, where inappropriate AttributedElement.Kind is resolved as 
> UnknownAttribute.
>
> Following proposal removes all usages of AttributedElement.Kind from 
> Classfile API:
>
> https://github.com/openjdk/jdk-sandbox/pull/48/files
>
> Please let me know is there are any objections.
>
> Thanks,
>
> Adam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20230207/cdb830c1/attachment.htm>