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 approach. 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> wrote: > > 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 >
