WebSocket client API

[Joakim Erdfelt]

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.rappo at oracle.com> wrote:

> Hi Joakim,
>
> > On 20 Oct 2015, at 13:50, Joakim Erdfelt <joakim.erdfelt at 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?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20151020/11479f9c/attachment.html>