<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 02/12/2024 16:50, Brian Goetz wrote:<br>
</div>
<blockquote type="cite" cite="mid:23F712D7-0826-49E0-9AFC-2081DF5A25E4@oracle.com">
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.
<div class=""><br class="">
</div>
<div class="">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.</div>
</blockquote>
<p>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>
<p>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>
<p>
<blockquote type="cite">
<div style="background-color:#ffffff;color:#000000">
<pre style="font-family:'Fira Code',monospace;font-size:12.8pt;"><span style="color:#808080;font-style:italic;">* Printing is for debugging purposes only. Printed text schema, tree content and structure
</span><span style="color:#808080;font-style:italic;">* not guaranteed. It may change anytime in a future.</span></pre>
</div>
</blockquote>
Is, IMHO, a big red herring.</p>
<p>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>
<p>Cheers<br>
Maurizio<br>
</p>
<blockquote type="cite" cite="mid:23F712D7-0826-49E0-9AFC-2081DF5A25E4@oracle.com">
<div class=""><br class="">
</div>
<div class=""><br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Dec 2, 2024, at 2:51 AM, Adam Sotona <<a href="mailto:adam.sotona@oracle.com" class="moz-txt-link-freetext" moz-do-not-send="true">adam.sotona@oracle.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
<span style="font-size: 11pt;" class="">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 class=""></o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
<span style="font-size: 11pt;" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
<span style="font-size: 11pt;" class="">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 class=""></o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
<span style="font-size: 11pt;" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
<span style="font-size: 11pt;" class="">I have no
objections to unify sub-int return types to int.<o:p class=""></o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
<span style="font-size: 11pt;" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
<span style="font-size: 11pt;" class="">Thanks,<o:p class=""></o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
<span style="font-size: 11pt;" class="">Adam<o:p class=""></o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
<span style="font-size: 11pt;" class=""><o:p class=""> </o:p></span></div>
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
<span style="font-size: 11pt;" class=""><o:p class=""> </o:p></span></div>
<div id="mail-editor-reference-message-container" class="">
<div class="">
<div class="">
<div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(181, 196, 223); padding: 3pt 0in 0in;" class="">
<p class="MsoNormal" style="margin: 0in 0in 12pt; font-size: 12pt; font-family: Aptos, sans-serif;">
<b class=""><span style="" class="">From:<span class="Apple-converted-space"> </span></span></b><span style="" class="">classfile-api-dev <<a href="mailto:classfile-api-dev-retn@openjdk.org" class="moz-txt-link-freetext" moz-do-not-send="true">classfile-api-dev-retn@openjdk.org</a>>
on behalf of Chen Liang <<a href="mailto:liangchenblue@gmail.com" class="moz-txt-link-freetext" moz-do-not-send="true">liangchenblue@gmail.com</a>><br class="">
<b class="">Date:<span class="Apple-converted-space"> </span></b>Monday,
2 December 2024 at 0:03<br class="">
<b class="">To:<span class="Apple-converted-space"> </span></b>Brian
Goetz <<a href="mailto:brian.goetz@oracle.com" class="moz-txt-link-freetext" moz-do-not-send="true">brian.goetz@oracle.com</a>><br class="">
<b class="">Cc:<span class="Apple-converted-space"> </span></b>classfile-api-dev
<<a href="mailto:classfile-api-dev@openjdk.org" class="moz-txt-link-freetext" moz-do-not-send="true">classfile-api-dev@openjdk.org</a>><br class="">
<b class="">Subject:<span class="Apple-converted-space"> </span></b>Re:
More last minute changes for the ClassFile
API<o:p class=""></o:p></span></p>
</div>
<div class="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
Hmm, for components package, I did a quick
rundown in<span class="Apple-converted-space"> </span><a href="http://grep.app/" style="color: blue; text-decoration: underline;" class="" moz-do-not-send="true">grep.app</a><span class="Apple-converted-space"> </span>search
(previously used for terminally deprecating
ZipError) and a search within JDK source:<o:p class=""></o:p></div>
<div class="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
1. A search on<span class="Apple-converted-space"> </span><a href="http://grep.app/" style="color: blue; text-decoration: underline;" class="" moz-do-not-send="true">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.<o:p class=""></o:p></div>
</div>
<div class="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
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 class=""></o:p></div>
</div>
<div class="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
<o:p class=""> </o:p></div>
</div>
<div class="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
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 class=""></o:p></div>
</div>
<div class="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
<o:p class=""> </o:p></div>
</div>
<div class="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
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 class=""></o:p></div>
</div>
<div class="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
<o:p class=""> </o:p></div>
</div>
<div class="">
<div style="margin: 0in; font-size: 12pt; font-family: Aptos, sans-serif;" class="">
Chen</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br class="">
</div>
</blockquote>
</body>
</html>