<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><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:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@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">I have found the ClassPrinter to be a useful debugging tool.</p><p class="MsoNormal"> </p><p class="MsoNormal">Mark</p><p class="MsoNormal"> </p><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b>From:</b> classfile-api-dev <<a href="mailto:classfile-api-dev-retn@openjdk.org">classfile-api-dev-retn@openjdk.org</a>> <b>On Behalf Of </b>Chen Liang<br><b>Sent:</b> Sunday, December 1, 2024 3:03 PM<br><b>To:</b> Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>><br><b>Cc:</b> classfile-api-dev <<a href="mailto:classfile-api-dev@openjdk.org">classfile-api-dev@openjdk.org</a>><br><b>Subject:</b> Re: More last minute changes for the ClassFile API</p></div><p class="MsoNormal"> </p><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:</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.</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.</p></div><div><p class="MsoNormal"> </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.</p></div><div><p class="MsoNormal"> </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?</p></div><div><p class="MsoNormal"> </p></div><div><p class="MsoNormal">Chen</p></div></div><p class="MsoNormal"> </p><div><div><p class="MsoNormal">On Sun, Dec 1, 2024 at 10:24 AM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>> wrote:</p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"><p class="MsoNormal">I have always been uncomfortable with the components package. But it is also pretty late in the cycle. <br><br>> On Dec 1, 2024, at 9:40 AM, Chen Liang <<a href="mailto:liangchenblue@gmail.com" target="_blank">liangchenblue@gmail.com</a>> wrote:<br>> <br>> <br>> Hello,<br>> In the week before RDP 1, I think there are still a few enhancements that require removal of existing APIs:<br>> 1. The components package. The utilities in this package are often inconsistent; for example, class name remapper does not remap simple names in InnerClasses; the locals shifter shifts an arbitrary number of slots. These inconsistent behaviors will have to be kept even if they make no sense in the long run, because people might have dependencies on these behaviors. I think we should move these components to example snippets for users, much like the System exit detection example in JEP 486.<br>> 2. The return types of PoolEntry::tag and AnnotationValue::tag. They currently return byte and char respectively while their constants are of int type. In addition, the byte tag can overflow if the constant pool tags exceed 127, and by then the default Java widening conversion would be erroneous for the constant pool tags.<br>> <br>> What do you think?<br>> Regards</p></blockquote></div></div></body></html>