WebSocket

[Chuck Davis]

> ByteBufferInputStream bbis = new ByteBufferInputStream();
> for each partial ByteBuffer received by the listener {
>   bbis.add(byteBuffer);
> }
> ois = new ObjectInputStream(bbis);
> MyDTO = ois.readObject();
>
> Now, ByteBufferInputStream is not present in the JDK, and if you want
> to complain you are in good (and conspicuous) company, as the JDK
> engineers appear to avoid the issue since years now (e.g. create a
> String from a ByteBuffer without copy).
> Having said that, the class is trivial to implement (a naive version I
> wrote is about 30 lines) and may even be provided as a utility class
> by the JDK WebSocket implementers.
>
> The advantage is that ByteBufferInputStream can be written in a way
> that performs *zero* copies, thanks to the JDK 9 WebSocket APIs -
> add() would need to return a CompletableFuture.
> If you don't want to confront with CompletableFutures, it can be
> written in a way that performs just one copy.
>

Simone, please, please tell me how this is done.  I'm too dense to see it.
I really REALLY do not like my vision of reassembling all the bits and
pieces so that deserialization can occur.  It's critically important that I
learn the BEST way to get thousands of rows from my database to my client.
At this point I'm contemplating whether I'd be better off giving up the
bidirectional advantage of WebSocket and going back to RMI.  If I
absolutely needed server push I could implement a JMS but that is a huge
increase of complexity.  How do I reassemble everything with *zero* or only
1 copy?

Thanks and I will forever be your debtor!!!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/net-dev/attachments/20180220/ddfa9ae9/attachment.html>