Upon a closer look, switching to ByteBuffer would only get you 50% towards where you want to be: the resulting ByteBuffer, whether encoded or decoded, is *allocated* by the respective methods and then returned as a result rather than accepted by those methods as a parameter.
> On 14 Dec 2023, at 19:57, Pavel Rappo <pavel.ra...@oracle.com> wrote: > > > >> On 14 Dec 2023, at 06:10, Magnus <magnus.eriks...@gmail.com> wrote: >> >> In the java libraries there are many methods that operate on byte arrays >> that do not allow you to specify offset and length for the relevant data >> instead forcing you to copy the relevant part to new arrays before using the >> methods reducing performance - I am for instance struggling with this in >> java.util.Base64 where the Encoders and Decoders lack a length parameter >> (also an offset would have been great even though I don't need that in my >> case). > > Re: java.util.Base64. Encoder and Decoder also seem to be able to work with > ByteBuffer. If you have an array, you can cheaply create a ByteBuffer wrapper > around that array. The now-backing array would be read or written though from > the specific position and up to the specific limit. Would that help? > > -Pavel >
