<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Making the output fully symmetrical might be a little bit more challenging (interesting?) than it seemed to be at first glance. You'd have to think about questions like "should the buffer be direct?". We could possibly allow an `IntFunction<ByteBuffer>` to be passed in, to support flexible allocation strategies and to allow (for example) writing to memory-mapped areas and things like that. Since we're currently doing a couple of `arraycopy` to write to the output, it should be trivial to create a variation which bulk-writes to a user-supplied `ByteBuffer`. This would be more broadly useful than just a naive `ByteBuffer.wrap()` on the byte array output. That effect could however still be achieved if the user passes in e.g. `ByteBuffer::allocate` as the buffer acquisition function (we could possibly supply an overload which uses this strategy).</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Mon, Mar 10, 2025 at 1:18 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com">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"><u></u>

  
  <div>
    <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>On 3/10/2025 2:13 PM, David Lloyd
      wrote:<br>
    </div>
    <blockquote type="cite">
      
      <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">
          <div dir="ltr" class="gmail_attr">On Mon, Mar 10, 2025 at
            12:52 PM Brian Goetz <<a href="mailto:brian.goetz@oracle.com" target="_blank">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>
  </div>

</blockquote></div><div><br clear="all"></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div>