Discussion: Efficient ByteBuffer -> String that avoids additional copying

[Xueming Shen]

On 5/16/18, 10:03 AM, Claes Redestad wrote:
> Hi,
>
> I'd just like to point out there's been some recent effort on this, see:
>
>  https://bugs.openjdk.java.net/browse/JDK-8021560
>
> .. which was RFR'd here:
>
>  http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-February/051401.html 
>
>
> I'm not sure what the current status of that is, but seems there's 
> more than
> a bit of overlap with what's being suggested here.

It started to appear Charset.De/Encoder might be a better place for 
String/ByteBuffer
decoding/encoding operations, convenient methods included, given the 
"complicated"
nature of decoding/encoding lifecircle management (shift-in, shfit-out, 
or even the
utf16 bom status, when the passed in output ByteBuffer does not have 
enough space,
for example). No final decision/proposal yet.

-Sherman


>
> /Claes
>
> On 2018-05-16 18:42, Jacob Glickman wrote:
>> Paul,
>>
>> Would you mind explaining more about what you're looking for regarding
>> this?  I'm curious if `ByteBuffer#getString` is what you're after, or
>> rather something similar to `String.from(ByteBuffer)`.  I'll definitely
>> have a look at jdk.internal.misc.SharedSecrets in the meantime.  Thanks!
>>
>> - Jacob
>>
>>> Hi Jacob,
>>> I do have one idea (that i don’t think is currently represented as a 
>>> bug,
>> though i have not searched JBS), if you are willing to take it on. It 
>> will
>> require some investigation, and careful testing, it’s not necessarily a
>> starter bug :-), but i can help guide.
>>> Investigate new methods to more efficiently support ByteBuffer -> 
>>> String
>> method on ByteBuffer that can avoid additional copying and 
>> makeappropriate
>> use of charsets given String’s compact string support. You need to 
>> look at
>> jdk.internal.misc.SharedSecrets for clues on how to trampoline 
>> between the
>> nio and lang packages.
>>> Paul.
>