Yes, overloads that accepted both source and destination ByteBuffer were there
at some point, but then were removed:
commit 591834e28d482ea6a375ab215958e1635a7b111d
Author: Xueming Shen <sher...@openjdk.org>
Date: Tue Dec 3 17:44:31 2013 -0800
8028397: Undo the lenient MIME BASE64 decoder support change (JDK-8025003)
and remove methods de/encode(buf, buf)
Updated the spec and implementation as requested
Reviewed-by: alanb
Let me paste the respective JBS description here for readers convenience:
The change set for "lenient mime decoder" support change (JDK-8025003) does not
meet the requirement needed by the submitter and there is different
understanding and opinion of what the "lenient" should be for the Base64
decoder. Given we are in late stage of the release. The decision is to back out
the change and leave the functionality for future releases.
Also during the discussion, it became clear that the decode/encode(ByteBuffer,
ByteBuffer) method pair are insufficient to support the requested de/encoding
continuation functionality ("underflow" handling, in charset coder's term).
Given the the most usage of these pair is for the channel read/writing, it
appears it might be more useful/desired to provide a pair of
wrap(readable/writableByteChannel) methods stead. While the wrap(channel)
methods are under development, it does not appear it will make jdk8. For jdk8
we have decided to remove the decode/encode(Buffer, Buffer).
> On 14 Dec 2023, at 20:24, Pavel Rappo <pavel.ra...@oracle.com> wrote:
>
> 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
>>
>
