Class files in ByteBuffer

[David Lloyd]

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

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

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

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