<!DOCTYPE html><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
  </head>
  <body>
    <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.  <br>
      <br>
      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>
      <br>
    </font><br>
    <div class="moz-cite-prefix">On 3/10/2025 1:38 PM, David Lloyd
      wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:CANghgrQf44YJ0tux4QVpL0HU2aKoQhdh17kAsQ6JHW6-sV5__g@mail.gmail.com">
      
      <div dir="ltr">
        <div>
          <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">When defining
            a class in the JDK, one may either use a byte array or a
            byte buffer to hold the contents of the class. The latter is
            useful when (for example) a JAR file containing uncompressed
            classes is mapped into memory. Thus, some class loaders
            depend on this form of the API for class definition.</div>
        </div>
        <div><br>
        </div>
        <div>
          <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">If I were to
            supplement such a class loader with a class transformation
            step based on the class file API, I would have to copy the
            bytes of each class on to the heap as a byte[] before I
            could begin parsing it. This is potentially expensive, and
            definitely awkward.</div>
          <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
          </div>
          <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">After
            transformation, it doesn't really matter if you have a
            byte[] or ByteBuffer because either way, the class can be
            defined directly.</div>
          <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
          </div>
          <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">It would be
            nice if the class file parser could accept either a byte[]
            or a ByteBuffer. I did a quick bit of exploratory work and
            it looks like porting the code to read from a ByteBuffer
            instead of a byte[]  (using ByteBuffer.wrap() for the array
            case) would be largely straightforward *except* for the code
            which parses UTF-8 constants into strings. Also there could
            be some small performance differences (maybe positive, maybe
            negative) depending on how the buffer is accessed.</div>
        </div>
        <div>
          <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
          </div>
          <div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Is this
            something that might be considered?</div>
        </div>
        <div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br>
        </div>
        <span class="gmail_signature_prefix">-- </span><br>
        <div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">
          <div dir="ltr">- DML • he/him<br>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
  </body>
</html>