I've been using jdk8 websockets to develop my desktop java
applications. Now that jdk9 is on my machine I started looking at
websockets and I'm not at all sure I like what I see. Can someone
familiar with this feature please explain the rationale for what is
happening?
I'm concerned, at this ini
g post of what it would look like if
> Java EE/EE4J were to adopt Reactive Streams everywhere, as it happens this
> also includes proposals for using Reactive Streams in the JSR 356 WebSocket
> spec:
>
> https://developer.lightbend.com/blog/2018-02-06-reactive-streams-ee4j/inde
Hi Pavel:
Thanks for your input. You guys are a lot smarter than I am so I
won't pretend to have a situation you haven't thought about.
My typical use case is to fetch database data from the server using
ejb. I return the data in serialized java objects to my JavaFX
clients (websockets are not
Thanks, Pavel, for the additional information.
Text payloads will be easily handled. ByteBuffers not so much
apparently. Major issues I see now: they can't grow and all the
methods I'd want to use are abstract, optional or both. So each
implementation I run on will have to be tested to see if
There is a great hush here regarding strategy for putting the pieces
back together so here goes my tirade.
Following is based on assumption of a 100k payload.
With jdk8:
The decoder received a ByteBuffer
bais = new ByteArrayInputStream(ByteBuffer.array()); // wrap the
buffer -- optional method b
James, who taught you how to ruin other people's days? You seem to have
mastered the art..😐
There seems to be a move afoot to abandon serialization.hummm. Then it
needs to get fixed because converting everything to a text stream before
transmitting is not an option (for me at least). Th
s to be a great leap forward. I maintain we
need both.
On Mon, Feb 19, 2018 at 3:45 AM, Chris Hegarty
wrote:
>
> On 18/02/18 20:12, Chuck Davis wrote:
>
>> ...
>>
>> RESULT: The formerly fabulous WebSocket has been rendered relatively
>> useless as a platform
Further thought...
Maybe a single WebSocket but two different listeners the developer can
choose depending upon what type of stream is expected???
Hi Simone:
Thanks for jumping in with your thoughts.
On Mon, Feb 19, 2018 at 12:19 PM, Simone Bordet
wrote:
> Hi,
>
> Well, not so fast.
> There are a lot of assumptions in the above code.
> The first is that the ByteBuffer has a backing array, which may not be the
> case.
> If you write the ri
> 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
Thank you so much for your assistance, Simone.
On Tue, Feb 20, 2018 at 10:31 AM, Simone Bordet
wrote:
> Hi,
>
> On Tue, Feb 20, 2018 at 4:32 PM, Chuck Davis wrote:
> > Simone, please, please tell me how this is done.
>
>
> This version has the advantage that guarante
James, this does not make any sense to me. Last I heard browsers no longer
run java. Why would JSE give a hang about designing a communications
mechanism for browsers on the client side? That is the job of the browser
developers. On the other hand, JSE WebSocket is the best thing to come
along
Well, yes, WebSocket on the server is an entirely different beast (at this
time -- although perhaps jdk9 WebSocket will make it's way to JEE someday)
-- and that definitely has to work with browsers. But the whole world is
not going to browsers as much as some would have us believe. The desktop
i
13 matches
Mail list logo
