ByteBuffer to CharBuffer

Jay jay.sridhar at
Tue Feb 7 08:03:29 UTC 2017

As a view of the underlying contents, I guess it is correct that no
encoding is applied to coerce a ByteBuffer into a CharBuffer. Maybe
the javadoc for ByteBuffer.asCharBuffer() can emphasize this point. It
is a bit confusing that most places in the JDK where bytes are
converted to chars, a Charset is usually involved whereas here we have
a low level operation - coercing bytes into chars.

On Tue, Feb 7, 2017 at 6:17 AM, Brian Burkhalter
<brian.burkhalter at> wrote:
> Looping in nio-dev which, as Pavel noted, is the apt forum for this topic.
> Jonas’s response is correct. The concept of “view buffer” is specified by
> [1]. In particular the statement
> "A view buffer is simply another buffer whose content is backed by the byte
> buffer."
> at least to my interpretation signifies that the content of the view buffer
> is conceptually mapped bit-by-bit to / from the corresponding bits in the
> byte buffer. The details are of course subject to byte order and the like,
> and the interpretation of the bits for floating point values is according to
> IEEE 754. There is however no encoding or decoding applied.
> - Brian
> [1]
> On Feb 6, 2017, at 5:35 AM, Jonas Konrad <me at> wrote:
> From what I can tell, asCharBuffer behaves exactly like the other as*Buffer
> methods, meaning every char in the CharBuffer is represented by two bytes in
> the original ByteBuffer (big- or little-endian depending on ByteOrder of the
> ByteBuffer). This means bb.asCharBuffer().get() behaves like bb.getChar().
> asCharBuffer does *not* decode using any Charset (not the platform charset
> either), it just interprets the bytes as 16-bit unsigned integers which
> happen to be the char type in java. I guess this technically counts as
> UTF-16? It doesn't do validity checks either, though.
> If you wish to decode a ByteBuffer, you can use the CharsetDecoder API
> directly. I do not believe an asCharBuffer-like method which decodes on the
> fly is possible generally for all charsets, because decoding is not
> necessarily possible in a random-access buffer due to dynamic-width
> encoding.
> - Jonas Konrad
> On 02/06/2017 11:57 AM, Jay wrote:
> java.nio.ByteBuffer provides a method asCharBuffer() which returns a
> "view" of the ByteBuffer as a character buffer. It however does not
> take any arguments. And there is no mention in the Javadocs as to how
> it converts from bytes to chars.
> 1. There should be a method ByteBuffer.asCharBuffer(CharSet) and/or
> ByteBuffer.asCharBuffer(String charSet) which allows the user to
> explicitly specify the character set to be used for conversion.
> 2. The method ByteBuffer.asCharBuffer() should mention that this
> method uses the platform default charset for bytes-to-chars
> conversion.
> I can provide a patch with these two changes. What do you guys think?


More information about the core-libs-dev mailing list