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.
