Hi Chris and others:

There is only one WebSocket documented in jdk9.  I was happy to be able to
write a jdk9 client that connected to my server unchanged (using
Wildfly11).  And there are features of jdk9 API that I rather like.

There are two vastly differing handling requirements.  I certainly am not
smart enough to figure out how to handle both in the same implementation.

With all credit to James the need to send Java objects over a wire is not
going to go away anytime soon.  But deserialization cannot commence until
the entire payload generated by the ObjectOutputStream is in a single
buffer at the destination (whether client or server).  Let's call this the
buffer  processing approach.

Then you have the crowd who need to process a stream.... of music, video or
you name it.  In that case you want the jdk9 approach to process smaller
bits of the stream as they arrive.  Let's call this the stream processing

While both approaches are streams the streams are so vastly different I
don't see any way to process them both with a single API implementation.
But as I said, I am not the sharpest knife in the drawer and maybe you guys
have the smarts to pull it off.  I certainly hope so.  The current jdk9
implementation is not suitable for data-driven applications that have to
process a buffer.  Putting all the pieces back together is prohibitively
expensive in time and resources.  For those who need to process a stream
the jdk9 implementation appears to be a great leap forward.  I maintain we
need both.

On Mon, Feb 19, 2018 at 3:45 AM, Chris Hegarty <chris.hega...@oracle.com>

> On 18/02/18 20:12, Chuck Davis wrote:
>> ...
>> RESULT:  The formerly fabulous WebSocket has been rendered relatively
>> useless as a platform for building responsive, bidirectional
>> client/server applications.  Am I the only person who sees this as a
>> HUGE regression of functionality??  I am ALARMED by this turn of
>> events.
> A point of clarification that may, or may not, be obvious
> to readers of this thread.
> The WebSocket API, with JDK 8, that is being compared is the
> Java EE API for WebSocket [1]. It is completely orthogonal to
> the proposed Java SE WebSocket API. Users of said API can
> continue to use it, if it meets their needs. Nothing being
> proposed here has any impact on it.
> The Java EE API for WebSocket provides higher-level API
> abstractions for handling whole and partial messages, decoding
> and encoding, etc. The proposed Java SE WebSocket API is a
> less-verbose, lower-level, API. They are two separate and
> distinct APIs. If one desires the the higher-level abstractions
> provided by the EE API, that is absolutely fine.
> The SE WebSocket API is not a replacement for the EE API, it
> is a lower-level alternative with simpler abstractions. A
> consequence of its simplicity is that a developer may need
> to do more to handle the data, but in many cases this is
> exactly what it wanted. These APIs complement each other
> rather than compete.
> -Chris
> [1] https://docs.oracle.com/javaee/7/api/javax/websocket/package
> -summary.html

Reply via email to