<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4"><font face="monospace">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.<br>
      </font></font><br>
    <div class="moz-cite-prefix">On 8/7/2023 6:46 AM, Adam Sotona wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CY4PR1001MB2150C4FBB6439AEF20392CEB8C0CA@CY4PR1001MB2150.namprd10.prod.outlook.com">
      
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style>@font-face
        {font-family:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}@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;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:10.0pt;
        font-family:"Calibri",sans-serif;}p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0cm;
        margin-right:0cm;
        margin-bottom:0cm;
        margin-left:36.0pt;
        font-size:10.0pt;
        font-family:"Calibri",sans-serif;}.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}div.WordSection1
        {page:WordSection1;}ol
        {margin-bottom:0cm;}ul
        {margin-bottom:0cm;}</style>
      <div class="WordSection1">
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">That makes perfect sense, attribute safety is
            more exactly an attribute transformation safety.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">I agree that introduction of special read/write
            filters (in a form of context options) is confusing and
            non-systematic.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">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).<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">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.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">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.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">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).<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">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.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">I propose to add following set of filtering
            transformations:<o:p></o:p></span></p>
        <ul style="margin-top:0cm" type="disc">
          <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l4 level1 lfo3"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">ClassTransform.ACCEPT_ALL_KNOWN_ATTRIBUTES<o:p></o:p></span></li>
          <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l4 level1 lfo3"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">ClassTransform.ACCEPT_ALL_SAFE_ATTRIBUTES<o:p></o:p></span></li>
          <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l4 level1 lfo3"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">FieldTransform.ACCEPT_ALL_KNOWN_ATTRIBUTES
              <o:p></o:p></span></li>
          <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l4 level1 lfo3"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">FieldTransform.ACCEPT_ALL_SAFE_ATTRIBUTES<o:p></o:p></span></li>
          <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l4 level1 lfo3"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">MethodTransform.ACCEPT_ALL_KNOWN_ATTRIBUTES<o:p></o:p></span></li>
          <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l4 level1 lfo3"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">MethodTransform.ACCEPT_ALL_SAFE_ATTRIBUTES<o:p></o:p></span></li>
          <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l4 level1 lfo3"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">CodeTransform.ACCEPT_ALL_KNOWN_ATTRIBUTES<o:p></o:p></span></li>
          <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l4 level1 lfo3"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">CodeTransform.ACCEPT_ALL_SAFE_ATTRIBUTES<o:p></o:p></span></li>
        </ul>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">Thanks,<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="font-size:11.0pt;mso-fareast-language:EN-US" lang="EN-US">Adam<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">Brian
                  Goetz <a class="moz-txt-link-rfc2396E" href="mailto:brian.goetz@oracle.com"><brian.goetz@oracle.com></a><br>
                  <b>Date: </b>Saturday, 5 August 2023 3:01<br>
                  <b>To: </b>Adam Sotona
                  <a class="moz-txt-link-rfc2396E" href="mailto:adam.sotona@oracle.com"><adam.sotona@oracle.com></a>,
                  <a class="moz-txt-link-abbreviated" href="mailto:classfile-api-dev@openjdk.org">classfile-api-dev@openjdk.org</a>
                  <a class="moz-txt-link-rfc2396E" href="mailto:classfile-api-dev@openjdk.org"><classfile-api-dev@openjdk.org></a><br>
                  <b>Subject: </b>Re: Attribute safety<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",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." 
                <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:
                <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. 
                <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. 
                <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. 
                <br>
                 - When transforming, keep HAZMAT attributes (lifting
                and lowering), but always drop UNKNOWN attributes.<br>
                 - When transforming, always drop HAZMAT and UNKNOWN
                attributes.  <br>
                <br>
                <br>
              </span></p>
            <p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>