Class files in ByteBuffer

[Brian Goetz]

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.

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.

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.


On 3/10/2025 1:38 PM, David Lloyd wrote:
> 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.
>
> 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.
>
> After transformation, it doesn't really matter if you have a byte[] or 
> ByteBuffer because either way, the class can be defined directly.
>
> 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.
>
> Is this something that might be considered?
>
> -- 
> - DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250310/e602ac67/attachment.htm>