<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;}
@font-face
{font-family:"Courier New \,serif";
panose-1:2 7 3 9 2 2 5 2 4 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
mso-margin-top-alt:auto;
margin-right:0cm;
mso-margin-bottom-alt:auto;
margin-left:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.apple-converted-space
{mso-style-name:apple-converted-space;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
mso-ligatures:none;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:542210653;
mso-list-template-ids:2017504096;}
@list l0:level1
{mso-level-tab-stop:36.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level2
{mso-level-tab-stop:72.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level3
{mso-level-tab-stop:108.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level4
{mso-level-tab-stop:144.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level5
{mso-level-tab-stop:180.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level6
{mso-level-tab-stop:216.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level7
{mso-level-tab-stop:252.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level8
{mso-level-tab-stop:288.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l0:level9
{mso-level-tab-stop:324.0pt;
mso-level-number-position:left;
text-indent:-18.0pt;}
@list l1
{mso-list-id:640381087;
mso-list-template-ids:2017504096;}
ol
{margin-bottom:0cm;}
ul
{margin-bottom:0cm;}
--></style>
</head>
<body lang="en-CZ" link="blue" vlink="purple" style="word-wrap:break-word;-webkit-nbsp-mode: space;line-break:after-white-space">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">I forgot about you last question:<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">“</span><span style="font-size:11.0pt">What should be the default here? PASS, or DROP_UNSTABLE?
</span><span lang="EN-US" style="font-size:11.0pt">“</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">In this context it seems to be safer to drop unstable by default, as for example almost any touch of code array will break type annotations.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">However some use cases explode code only to remove some attributes and removing also something else would be an unexpected behavior.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">So PASS is more expected behavior and DROP_UNSTABLE is more safe.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">I would keep the PASS as default to keep the library behavior more predictable.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div id="mail-editor-reference-message-container">
<div>
<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">classfile-api-dev <classfile-api-dev-retn@openjdk.org> on behalf of Adam Sotona <adam.sotona@oracle.com><br>
<b>Date: </b>Wednesday, 6 September 2023 10:31<br>
<b>To: </b>Brian Goetz <brian.goetz@oracle.com><br>
<b>Cc: </b>classfile-api-dev@openjdk.org <classfile-api-dev@openjdk.org><br>
<b>Subject: </b>Re: Attribute safety<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">OK, it makes sense, I’ll update pr/15101 to filter only bound attrs on write.</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">Thanks,</span><o:p></o:p></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;mso-fareast-language:EN-US">Adam</span><o:p></o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US"> </span><o:p></o:p></p>
<div id="mail-editor-reference-message-container">
<div>
<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>Tuesday, 5 September 2023 19:08<br>
<b>To: </b>Adam Sotona <adam.sotona@oracle.com><br>
<b>Cc: </b>classfile-api-dev@openjdk.org <classfile-api-dev@openjdk.org><br>
<b>Subject: </b>Re: Attribute safety</span><o:p></o:p></p>
</div>
<div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">I probably bgought a bit of confusion here. The pr/15101 is the original “global context option” proposal (just updated with the latest changes). It filters the attributes on read and on write
based on the context option. I found hard to determine when to write an attribute based on its bound or unbound origin. We cannot determine if user pass down the transformation a bound attribute intentionally or unintentionally (and so we should or should
not write it to the class).</span><o:p></o:p></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Yes, what I’m suggesting is not entirely precise, but the window of error is narrowed. We should filter nothing on read (since people ignore unsupported attributes). The remaining question is whether we
are comfortable discriminating against attributes based on a two-dimensional filter — Bound and “below the stability threshold”. This is a little messy but seems OK, and less coarse than the other options?</span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> Filtering at transformation would be an alternative way, where we don’t need any Classfile.</span><span style="font-size:11.0pt">AttributeProcessingO</span><span lang="EN-US" style="font-size:11.0pt">p</span><span style="font-size:11.0pt">tion</span><span lang="EN-US" style="font-size:11.0pt"> at
all. Parsed and written will be always everything and specific transformations will always explode and filter respective attributes at all class model levels.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">For example<span class="apple-converted-space"> </span></span><span lang="EN-US">ClassTransform.ACCEPT_ALL_SAFE_ATTRIBUTES will always explode class model down to the code and filter out all TypeAnnotations
(while ClassTransform.ACCEPT_ALL does not need to explode anything).</span><o:p></o:p></p>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Now that I think about it, filtering at transformation vs filtering at write — as long as we discriminate only against Bound attributes that are below the chosen stability threshold — are equivalent. So whichever
is easier for the implementation / API seems better, and filtering on write seems like it has both less runtime impact (no need to compose transformations) and less API impact (no new transform constants.)</span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<br>
</span><o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div id="mail-editor-reference-message-container">
<div>
<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">From:<span class="apple-converted-space"> </span></span></b><span style="font-size:12.0pt">Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>><br>
<b>Date:<span class="apple-converted-space"> </span></b>Tuesday, 5 September 2023 14:40<br>
<b>To:<span class="apple-converted-space"> </span></b>Adam Sotona <<a href="mailto:adam.sotona@oracle.com">adam.sotona@oracle.com</a>><br>
<b>Cc:<span class="apple-converted-space"> </span></b><a href="mailto:classfile-api-dev@openjdk.org">classfile-api-dev@openjdk.org</a> <<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: Attribute safety</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Some review comments on this patch. </span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Attributes with the LABELS stability need only be exploded and rewritten when the Code array is perturbed. In practicality, LABELS attributes will also contain CP refs, so the doc should really suggest “labels
*and* CP refs”. </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">HAZMAT can be renamed to UNSTABLE (yeah, I know HAZMAT is a cool name.)</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Doc on AttributeProcessingOPtion should make it clear that this is only during _transformation_; during reading/writing, all attributes are passed normally. What should be the default here? PASS, or DROP_UNSTABLE?
</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Now that the choices are simpler, I think you can add (constant) transforms for {CLASS,METHOD,FIELD,CODE}_drop{Unknown,Unstable}, and compose these in when the user calls transform() and the option setting
is not PASS_ALL?</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><br>
<br>
<br>
<br>
</span><o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On Sep 5, 2023, at 5:17 AM, Adam Sotona <<a href="mailto:adam.sotona@oracle.com">adam.sotona@oracle.com</a>> wrote:</span><o:p></o:p></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">I’ve updated<span class="apple-converted-space"> </span><a href="https://github.com/openjdk/jdk/pull/15101">https://github.com/openjdk/jdk/pull/15101</a><span class="apple-converted-space"> </span>so
it filters on read and write based on the Classfile.AttributesProcessingOption context option.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">Or I can prepare a patch with filtering transformations (as proposed below).</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">Or is there any other way?</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">Thanks,</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">Adam</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div id="mail-editor-reference-message-container">
<div>
<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">From:<span class="apple-converted-space"> </span></span></b><span style="font-size:12.0pt">Brian Goetz <<a href="mailto:brian.goetz@oracle.com">brian.goetz@oracle.com</a>><br>
<b>Date:<span class="apple-converted-space"> </span></b>Wednesday, 23 August 2023 19:26<br>
<b>To:<span class="apple-converted-space"> </span></b>Adam Sotona <<a href="mailto:adam.sotona@oracle.com">adam.sotona@oracle.com</a>>,<span class="apple-converted-space"> </span><a href="mailto:classfile-api-dev@openjdk.org">classfile-api-dev@openjdk.org</a><span class="apple-converted-space"> </span><<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: Attribute safety</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier New"">Just a further thought on this: we can further focus our lens on _bound_ attributes, because these are the ones that have come from another classfile.
If the user creates a RVAA during a transform, we should assume that is fine, just as we do with writing.</span><o:p></o:p></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">On 8/7/2023 6:46 AM, Adam Sotona wrote:</span><o:p></o:p></p>
</div>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">That makes perfect sense, attribute safety is more exactly an attribute transformation safety.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">I agree that introduction of special read/write filters (in a form of context options) is confusing and non-systematic.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">When we focus on the implementation of the attributes transformation safety, I think the safety switch is less of a global context option but rather individual transformation immediate feature
(a filtering feature).</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">If we implement it as a global context option, we would have to insert a filtering layer before each transformation (on read side) or after (on write side) of each transformation. I think it would
be pretty much the same as filtering on read/write, except for the fact it will affect transformations only (so maybe even more confusing). Classfile::transform would then behave differently than its expanded form using Classfile::build.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">However if we implement attribute transformation safety as specific transformations (doing the filtering job) – it should work in harmony with the rest of the API.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">For example in addition to ClassTransform.ACCEPT_ALL we can add ClassTransform.ACCEPT_ALL_KNOWN_ATTRIBUTES (dropping UNKNOWN) and ClassTransform.ACCEPT_ALL_SAFE_ATTRIBUTES (dropping HAZMAT).</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">As an interesting expansion of the ClassfileTransform features we can provide factories like for example ClassfileTransform::dropingAll(Predicate<ClassfileElement> filter) – where the “All” (or
“Deep” or similar suffix) should indicate forced expansion of the whole tree, so the filter is really applied on all levels and filtered element never appears in the target class. It can be used to implement the global filtering transformations.</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">I propose to add following set of filtering transformations:</span><o:p></o:p></p>
</div>
</div>
<ol style="margin-top:0cm" start="1" type="1">
<li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l0 level1 lfo3">
<span lang="EN-US">ClassTransform.ACCEPT_ALL_KNOWN_ATTRIBUTES</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l0 level1 lfo3">
<span lang="EN-US">ClassTransform.ACCEPT_ALL_SAFE_ATTRIBUTES</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l0 level1 lfo3">
<span lang="EN-US">FieldTransform.ACCEPT_ALL_KNOWN_ATTRIBUTES</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l0 level1 lfo3">
<span lang="EN-US">FieldTransform.ACCEPT_ALL_SAFE_ATTRIBUTES</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l0 level1 lfo3">
<span lang="EN-US">MethodTransform.ACCEPT_ALL_KNOWN_ATTRIBUTES</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l0 level1 lfo3">
<span lang="EN-US">MethodTransform.ACCEPT_ALL_SAFE_ATTRIBUTES</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l0 level1 lfo3">
<span lang="EN-US">CodeTransform.ACCEPT_ALL_KNOWN_ATTRIBUTES</span><o:p></o:p></li><li class="MsoListParagraph" style="margin-top:0cm;margin-bottom:0cm;mso-list:l0 level1 lfo3">
<span lang="EN-US">CodeTransform.ACCEPT_ALL_SAFE_ATTRIBUTES</span><o:p></o:p></li></ol>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">Thanks,</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt">Adam</span><o:p></o:p></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
<div id="mail-editor-reference-message-container">
<div>
<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">From:<span class="apple-converted-space"> </span></span></b><span style="font-size:12.0pt">Brian Goetz<span class="apple-converted-space"> </span><a href="mailto:brian.goetz@oracle.com"><brian.goetz@oracle.com></a><br>
<b>Date:<span class="apple-converted-space"> </span></b>Saturday, 5 August 2023 3:01<br>
<b>To:<span class="apple-converted-space"> </span></b>Adam Sotona<span class="apple-converted-space"> </span><a href="mailto:adam.sotona@oracle.com"><adam.sotona@oracle.com></a>,<span class="apple-converted-space"> </span><a href="mailto:classfile-api-dev@openjdk.org">classfile-api-dev@openjdk.org</a><span class="apple-converted-space"> </span><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: Attribute safety</span><o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:13.5pt;font-family:"Courier New \,serif"">OK, I thought about this some more while sitting in the sauna ...<br>
<br>
I think the locus of attribute safety is not reading or writing, but transforming. If I am just going to read a classfile, there is no need to drop anything, if I find an attribute I don't recognize, I'll just skip over it and keep going -- that's how attributes
are designed to work. No need to drop anything on read, ever. WHen the library finds an unknown attribute, it wraps it with an UnknownAttribute element, whose understanding to the attribute is limited to name, size, and byte[] of the payload. Nothing so
dangerous here that the user needs protection.<br>
<br>
Similarly, if a user is _writing_ a classfile, again, we should trust them that the classfile they are putting together is sensible. We shouldn't second guess at "oh, that's a type annotations attribute, those are so brittle, please sign here." <span class="apple-converted-space"> </span><br>
<br>
Where there is potentially a problem is when we are _transforming_ a classfile, because for a HAZMAT or UNKNOWN attribute, we can't guarantee its integrity if we've changed anything else about the classfile (including reordering the constant pool.) So the
"what do we do with brittle attributes" question applies only to transformation, where we are taking an attribute from one classfile (a bound attribute) and writing it to another. This is where the user can shoot themselves in the foot, because they might
change something else about the classfile and subtly (or not subtly) undermine the integrity of the annotation they don't understand. And this is why we want to classify attributes according to their sensitivity to environmental change:<span class="apple-converted-space"> </span><br>
<br>
- A stateless attribute is sensitive to no environmental changes. A transform can always safely bulk-copy the attribute directly.<br>
<br>
- An attribute with CP dependencies is sensitive to restructuring of the constant pool (no CP sharing), but the mapper contains enough information to survive CP restructuring. A transform can safely bulk-copy the attribute directly if the CP is shared between
the original and new classfile, and can otherwise safely copy the attribute by inflating it and deflating it via the readAttribute/writeAttribute behavior of the mapper. <span class="apple-converted-space"> </span><br>
<br>
- An attribute with label dependencies is sensitive to changes to the contents or structure of the bytecode array. A transform can safely bulk-copy the attribute directly if code array is unchanged, and can otherwise safely copy the attribute by inflating
it and deflating it via the readAttribute/writeAttribute behavior of the mapper. However, there are currently no attributes that have label dependencies only but are not already treated specially by the classfile API, so this category may not be that interesting.<br>
<br>
- An attribute with unpredictable dependencies is sensitive to any change to the contents of the entity of which it is an attribute. It can be safely bulk-copied if nothing else in that entity has changed, but otherwise there is no safe way to copy it. <span class="apple-converted-space"> </span><br>
<br>
- An unknown attribute is sensitive to all of the above, and so takes on the union of the copying risks of all of the above.<br>
<br>
So I think the Option we want governs what to do with various attributes when _transforming_ a CompoundElement in which they appear. And the problematic cases are those with unpredictable dependencies, and unknowns. So I think the options we want are:<br>
<br>
- When transforming, always keep HAZMAT and UNKNOWN attributes; for safety, lift and lower HAZMAT attributes. <span class="apple-converted-space"> </span><br>
- When transforming, keep HAZMAT attributes (lifting and lowering), but always drop UNKNOWN attributes.<br>
- When transforming, always drop HAZMAT and UNKNOWN attributes. </span><o:p></o:p></p>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<p class="MsoNormal"><span style="font-size:11.0pt"> </span><o:p></o:p></p>
</div>
</div>
</div>
</div>
</div>
</body>
</html>