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.burkhal...@oracle.com> 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] > http://download.java.net/java/jdk9/docs/api/java/nio/ByteBuffer.html#views > > On Feb 6, 2017, at 5:35 AM, Jonas Konrad <m...@yawk.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? > > -- Regards Jay
