<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <font size="4" face="monospace">So, the other half of this is the
      overloads for Classfile::buildToByteBuffer, which I assume has a
      similarly trivial initial implementation; we wouldn't want to do
      one without the other, as it will seem a gratuitous asymmetry.  If
      both are shallow implementations, I'm not averse to this -- though
      you'll probably want an @ImplNote that explains how the
      implementation works, to avoid unhappy performance surprises.  <br>
    </font><br>
    <div class="moz-cite-prefix">On 3/10/2025 2:13 PM, David Lloyd
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CANghgrS0PM3WZ=9SHeoV8-92XxzrWwTxf3zjP1Nk-MG6v9Xvcg@mail.gmail.com">
      
      <div dir="ltr">
        <div dir="ltr">
          <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks for
            the response; comments inline.</div>
        </div>
        <br>
        <div class="gmail_quote gmail_quote_container">
          <div dir="ltr" class="gmail_attr">On Mon, Mar 10, 2025 at
            12:52 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" moz-do-not-send="true" class="moz-txt-link-freetext">brian.goetz@oracle.com</a>>
            wrote:<br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div> <font face="monospace" size="4">It sounds like you
                are asking two questions.  At the API level, you are
                asking whether adding a Classfile.parse(ByteBuffer)
                method would be in scope.  But at the implementation
                level, you are asking whether we would be OK to make
                ByteBuffer *the primitive* on which processing the
                byte[] format is based, which is a more intrusive
                change.  <br>
                <br>
                My first reaction is that the first seems fine in
                theory, but if the only reasonable implementation
                strategy is the latter, then I am pretty skeptical.</font> </div>
          </blockquote>
          <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
          </div>
          <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
            <div><font face="monospace" size="4"> A ByteBuffer-accepting
                factory that simply copied to a byte[] would be fine
                (this is what we do with the existing Path-accepting
                factory, it's a similar form of convenience), but it
                sounds like this would not make you any happier.<br>
              </font></div>
          </blockquote>
          <div><br>
          </div>
          <div>
            <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Well, it
              honestly wouldn't make me unhappy, because it's not worse
              than today's status quo. If the API exists, then
              optimization is always going to be a future possibility.
              So I for one would be fine with this as a starting point,
              especially if it would greatly increase the chances of
              such an API being included in time for Java 25. Trying to
              find an optimal implementation strategy might be a
              diverting future spare-time project for someone (maybe
              even myself if I ever find enough of those elusive
              "round tuits" I keep hearing about).</div>
          </div>
          <div><br>
          </div>
        </div>
        <span class="gmail_signature_prefix">-- </span><br>
        <div dir="ltr" class="gmail_signature">
          <div dir="ltr">- DML • he/him<br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>