Class files in ByteBuffer

[Brian Goetz]

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.

On 3/10/2025 2:13 PM, David Lloyd wrote:
> 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/fd5bc887/attachment.htm>