Class files in ByteBuffer

David Lloyd david.lloyd at redhat.com
Mon Mar 10 18:13:39 UTC 2025


Thanks for the response; comments inline.

On Mon, Mar 10, 2025 at 12:52 PM Brian Goetz <brian.goetz at oracle.com> wrote:

> 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.
>

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).

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/classfile-api-dev/attachments/20250310/8caf9e42/attachment-0001.htm>


More information about the classfile-api-dev mailing list