<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;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.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 style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language: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>Monday, 12 September 2022 20:17<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: RFR: jdk.classfile.transforms package cleanup + javadoc<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"">This is a good improvement. I have a few additional suggestions and questions:<br>
<br>
- The ClassRemapper spec talks about what it _doesn't_ map, rather than what it does. We should characterize what it does do (e.g., for every ClassEntry referenced by an instruction, attribute, or metadata, map it to a new ClassEntry as per the contents of
the map...) It should also give a plain explanation of when you would use it (e.g., package renaming.)
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">Right, thanks, I’ll fix it.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier New""><br>
- You might want to give some example code for how to remap _all_ classes in package com.foo to com.bar -- this involves writing a Function that looks at prefixes.
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">There is such example “</span>Sample use with map function<span lang="EN-US">”, however not enough described and highlighted. I’ll fix it.</span><o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier New""><br>
- Does CodeLocalsShifter::addLocal work in concert with the local-allocation feature of BlockBuilder?
<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">Good point :)<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">It does not yet, however I’ll try to reimplement it to do so. We may get rid of counting the method arguments, local counting of “next”, use BlockBuilders instead of the “fork”, etc...<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier New""><br>
- Should explain why fork() exists<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">Maybe it doesn’t need to exist :)</span><span style="font-size:13.5pt;font-family:"Courier New""><br>
<br>
There is some question about what package these should go in. I think the current package "transforms" is probably not optimal.
<br>
<br>
- We could put these in the jdk.classfile package. There's only a handful of them, I think this would be OK.<br>
- We could put these in some package that suggests these are reusable components that are not part of the classfile API. But if so, "transform" is probably a little too specific, since one can imagine reusable components for other things (e.g., a pedantic
verifying builder wrapper, an AttributeBuilder for foreign but common attributes, if such a thing existed, etc.) "Util" is a little general (plus it has the feeling of a "dumping ground") but might be OK. ASM also has "commons", which has the suggestion
of "stuff contributed from the community", but that's also not a great name. <br>
<br>
The ASM "util" package contains: Trace/CheckClassAdapter and friends, ClassPrinter, etc. This feels in roughly the same category -- stuff you may want to use, but which are "components" rather than framework.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">I think “commons” was not the best choice for ASM, as it represent common (the bottom) parts of complex APIs in many external Java libraries.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">And I agree “transform” is too specific and “util” is probably too general. <o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">My personal preference would be “components”.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier New""><br>
</span><span lang="EN-US">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="EN-US">Adam<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>