<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=us-ascii">
<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:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:12.0pt;
font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Aptos",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">ClassRemapper, CodeLocalsShifter, CodeRelabeler and CodeStackTracker are single-purpose components standing on top of Class-File API and they have been carefully selected to support more complex use cases
(like for example code instrumentation). I partly agree they may be turned into examples. However, the learning curve will be extremely steep for users forced to implement them first instead of just use them.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">ClassPrinter is a different beast. This tool raised from serious needs and become significant complement to the API. It has been cleaned and simplified to its bare bones to avoid any confusion about its purpose.
Maybe the components package location for ClassPrinter is not ideal however it works to differentiate it from the core API.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I have no objections to unify sub-int return types to int.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Adam<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="color:black">From:
</span></b><span style="color:black">classfile-api-dev <classfile-api-dev-retn@openjdk.org> on behalf of Chen Liang <liangchenblue@gmail.com><br>
<b>Date: </b>Monday, 2 December 2024 at 0:03<br>
<b>To: </b>Brian Goetz <brian.goetz@oracle.com><br>
<b>Cc: </b>classfile-api-dev <classfile-api-dev@openjdk.org><br>
<b>Subject: </b>Re: More last minute changes for the ClassFile API<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal">Hmm, for components package, I did a quick rundown in <a href="http://grep.app">
grep.app</a> search (previously used for terminally deprecating ZipError) and a search within JDK source:<o:p></o:p></p>
<div>
<p class="MsoNormal">1. A search on <a href="http://grep.app">grep.app</a> shows there are no non-JDK usages of the components package; in contrast, all other classfile packages (attribute, instruction, constantpool) and the java.lang.constant package have
usages beyond the JDK. A search on GitHub shows there is no actual usages of components package, yet ClassPrinter.ListNode is frequently used in imports due to the name similarity with a class offered by Leetcode.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2. A search within the JDK itself shows there is no use of these components, besides ClassPrinter in JFR, outside of ClassFile API and its tests.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I think the removal at this point is safe; even for the ClassPrinter, its huge amount of data exposed is very prone to unintended dependencies, which can turn it into a monolith that we cannot adjust at all later down the road.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Also for the 2 return types: Is it fine for us to promote the return types to `int` to promote consistency with the constant fields?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Chen<o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>