<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="en-CZ" link="#0563C1" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Actually we have no use case to benchmark.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Newly proposed code simply does not check for appropriate “where applicable” during bound attributes parsing and passes the Attribute instance on anyway. There was no other use of that information across the Classfile
API.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Alternatively I can implement the check by single switch asking if the provided attribute is instanceof XyzElement according to the enclosing AttributedEleement type, and exchange it for UnknownAttribute if not appropriate.
In comparison to Set::contains there should be no regression. <o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Brian Goetz <brian.goetz@oracle.com><br>
<b>Date: </b>Tuesday, 7 February 2023 16:02<br>
<b>To: </b>Adam Sotona <adam.sotona@oracle.com>, classfile-api-dev@openjdk.org <classfile-api-dev@openjdk.org><br>
<b>Subject: </b>Re: Classfile API AttributedElement.Kind removal proposal</span><span style="font-size:12.0pt;color:black;mso-fareast-language:EN-GB"><o:p></o:p></span></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier New"">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. <br>
<br>
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.</span></p>
<div>
<p class="MsoNormal">On 2/7/2023 9:33 AM, Adam Sotona wrote:</p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal"><span lang="EN-US">Hi,</span></p>
<p class="MsoNormal"><span lang="EN-US">Based on discussion in the Classfile API PR:
</span><a href="https://github.com/openjdk/jdk/pull/10982#discussion_r1098601988"><span lang="EN-US">https://github.com/openjdk/jdk/pull/10982#discussion_r1098601988</span></a></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">I would like to propose removal of AttributedElement.Kind across all Classfile API.</span></p>
<p class="MsoNormal"><span lang="EN-US">The AttributedElement.Kind models Attributes “where applicable” and it is a duplication of each Attribute extending ClassElement, MethodElement, CodeElement, etc…</span></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">Classfile API is not actively using the AttributedElement.Kind except for parsing, where inappropriate AttributedElement.Kind is resolved as UnknownAttribute.</span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span lang="EN-US">Following proposal removes all usages of AttributedElement.Kind from Classfile API:</span></p>
<p class="MsoNormal"><a href="https://github.com/openjdk/jdk-sandbox/pull/48/files">https://github.com/openjdk/jdk-sandbox/pull/48/files</a></p>
<p class="MsoNormal"><span lang="EN-US"> </span></p>
<p class="MsoNormal"><span lang="EN-US">Please let me know is there are any objections.</span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"><span lang="EN-US">Thanks,</span></p>
<p class="MsoNormal"><span lang="EN-US">Adam</span></p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
</blockquote>
<p class="MsoNormal"><span style="mso-fareast-language:EN-GB"><o:p> </o:p></span></p>
</div>
</body>
</html>