<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:Aptos;
panose-1:2 11 0 4 2 2 2 2 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
@font-face
{font-family:"Fira Code";
panose-1:2 11 8 9 5 0 0 2 0 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;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
.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;line-break:after-white-space">
<div class="WordSection1">
<p class="MsoNormal">First a technical note: ClassPrinter is essential part of the Class-File API implementation, and at least its implementation cannot be moved out of the java.base module.</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Four years ago, we spent significant time on the ClassPrinter design, location, and format. In the current form we’ve released it in two JDK previews and ClassPrinter received positive feedback. Now, when the Class-File API has been finalized,
why should we nuke it and return to the drawing board?</p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’m missing the purpose of all the previews, feedbacks and API reviews.</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">Brian Goetz <brian.goetz@oracle.com><br>
<b>Date: </b>Monday, 2 December 2024 at 19:03<br>
<b>To: </b>Adam Sotona <adam.sotona@oracle.com><br>
<b>Cc: </b>Maurizio Cimadamore <maurizio.cimadamore@oracle.com>, Chen Liang <liangchenblue@gmail.com>, 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>
<p class="MsoNormal">My problem is not with ClassPrinter, but with the concept of a `components` package in general. The ones we have don’t really justify themselves, and it risks becoming either a dumping ground or a maintenance problem. Perhaps moving ClassPrinter
to the tests for the time being while we find a better place and API for it is a reasonable short-term move?</p>
<div>
<p class="MsoNormal"><br>
<br>
</p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On Dec 2, 2024, at 12:59 PM, Adam Sotona <<a href="mailto:adam.sotona@oracle.com">adam.sotona@oracle.com</a>> wrote:</p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I strongly disagree with removal of ClassPrinter, it become an essential tool.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">We refined its design in the early prototypes, introduced it in two previews. Adding print methods to ClassModel has been already discussed and denied.</span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
</div>
<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>From:<span class="apple-converted-space"> </span></b>Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>><br>
<b>Date:<span class="apple-converted-space"> </span></b>Monday, 2 December 2024 at 18:42<br>
<b>To:<span class="apple-converted-space"> </span></b>Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>><br>
<b>Cc:<span class="apple-converted-space"> </span></b>Adam Sotona <<a href="mailto:adam.sotona@oracle.com">adam.sotona@oracle.com</a>>, Chen Liang <<a href="mailto:liangchenblue@gmail.com">liangchenblue@gmail.com</a>>, classfile-api-dev <<a href="mailto:classfile-api-dev@openjdk.org">classfile-api-dev@openjdk.org</a>><br>
<b>Subject:<span class="apple-converted-space"> </span></b>Re: More last minute changes for the ClassFile API<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">If there are no JDK dependencies on the components package, we can propose to drop the entirety from 24 and bring back the relevant bits in 25. That’s a simple CSR.</p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">On Dec 2, 2024, at 12:39 PM, Maurizio Cimadamore <<a href="mailto:maurizio.cimadamore@oracle.com">maurizio.cimadamore@oracle.com</a>> wrote:</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">On 02/12/2024 16:50, Brian Goetz wrote:</p>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">My main concern with the single-purpose components is that I think they are in the wrong place. Co-locating them with the classfile API feels like it is promising more than we deliver, and users might feel they have to understand what
they do. <span class="apple-converted-space"> </span></p>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">I agree that the printing functionality is essential, and perhaps it doesn’t belong in components, especially if the rest off components is going away.</p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal">While I agree that some of the stuff in here seems useful, I'm not sure how much we want to commit to it.</p>
</div>
<div>
<p class="MsoNormal">Even if I look at ClassPrinter only, there's XML, Yaml and JSON output. These probably use a custom schema, which might, or might not fit the user needs. The fact that we even say:</p>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<pre style="background:white"><i><span style="font-size:13.0pt;font-family:"Fira Code";color:gray">* Printing is for debugging purposes only. Printed text schema, tree content and structure</span></i></pre>
<pre style="background:white"><i><span style="font-size:13.0pt;font-family:"Fira Code";color:gray">* not guaranteed. It may change anytime in a future.</span></i></pre>
</div>
</blockquote>
<div>
<p class="MsoNormal">Is, IMHO, a big red herring.</p>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<p class="MsoNormal">I think having a way to dump a class model in a textual form is a good thing (but I'd say that something like this can be achieved by adding some method to ClassModel, rather than having a separate component?). But the stuff in this package
seems relatively niche-y, and we'd be perhaps better off to leave this out, at least for now. If, in the future, we think that some of the components are sufficiently general to be added to the API, we can consider it? (e.g. we don't have to decide now?)</p>
</div>
<div>
<p class="MsoNormal">Cheers<br>
Maurizio</p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal">On Dec 2, 2024, at 2:51 AM, Adam Sotona <<a href="mailto:adam.sotona@oracle.com">adam.sotona@oracle.com</a>> wrote:</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<div>
<div>
<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.</span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
</div>
</div>
<div>
<div>
<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.</span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I have no objections to unify sub-int return types to int.</span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks,</span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Adam</span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span></p>
</div>
</div>
<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>From:<span class="apple-converted-space"> </span></b>classfile-api-dev <<a href="mailto:classfile-api-dev-retn@openjdk.org">classfile-api-dev-retn@openjdk.org</a>> on behalf of Chen Liang <<a href="mailto:liangchenblue@gmail.com">liangchenblue@gmail.com</a>><br>
<b>Date:<span class="apple-converted-space"> </span></b>Monday, 2 December 2024 at 0:03<br>
<b>To:<span class="apple-converted-space"> </span></b>Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>><br>
<b>Cc:<span class="apple-converted-space"> </span></b>classfile-api-dev <<a href="mailto:classfile-api-dev@openjdk.org">classfile-api-dev@openjdk.org</a>><br>
<b>Subject:<span class="apple-converted-space"> </span></b>Re: More last minute changes for the ClassFile API<o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Hmm, for components package, I did a quick rundown in<span class="apple-converted-space"> </span><a href="http://grep.app/">grep.app</a><span class="apple-converted-space"> </span>search (previously used for terminally deprecating ZipError)
and a search within JDK source:</p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">1. A search on<span class="apple-converted-space"> </span><a href="http://grep.app/">grep.app</a><span class="apple-converted-space"> </span>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.</p>
</div>
</div>
</div>
<div>
<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.</p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<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.</p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<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?</p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Chen</p>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</div>
</div>
</div>
</body>
</html>