The CharBuffer requirement *was* baffling. But we *think* we understand what you are trying to do.
Here's a split UTF8 scenario (just whipped up) https://gist.github.com/joakime/e34b727a6989ca7cef94 So the JVM implementation side will take the raw bytes (presumably as a ByteBuffer), and when the entire message is fully received it will convert it to a CharBuffer using the CharsetDecoder for UTF8 with REPORT logic to capture bad UTF8 sequences. Some concerns about this approach. 1. You can't fast-fail a large and fragmented TEXT message if the problematic UTF8 sequence occurs early (this is a spec test in the autobahn testsuite btw) 2. You can't use CharBuffer with partial TEXT message handling, as UTF8 sequences that are split across Frames will trigger the REPORT processing. (see gist/example above for this scenario) (also a spec test in the autobahn testsuite) 3. For each TEXT message, there's 2 data copies (ByteBuffer -> HeapCharBuffer -> String) for it to be practical to use in many 3rd party libs (eg JSON parsing). For large messages, this can get expensive. On Tue, Oct 20, 2015 at 5:57 AM, Pavel Rappo <pavel.ra...@oracle.com> wrote: > Hi Joakim, > > > On 20 Oct 2015, at 13:50, Joakim Erdfelt <joakim.erdf...@gmail.com> > wrote: > > > > You know that CharBuffer doesn't actually do UTF8, right? > > It's just a ByteBuffer split into equal 2 byte segments. > > CharBuffer is a way to obtain char (the 2 byte number, not the > character) from the ByteBuffer or String you created it from. > > CharBuffer is functionally no different than ShortBuffer. > > Yes, I'm fully aware of the difference between > java.nio.ByteBuffer#asCharBuffer > and java.nio.charset.CharsetDecoder#decode(java.nio.ByteBuffer). > > What's your point? > >
