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 t
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 a
Further thought...
Maybe a single WebSocket but two different listeners the developer can
choose depending upon what type of stream is expected???
Hi,
On Sun, Feb 18, 2018 at 9:12 PM, Chuck Davis wrote:
> 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 ByteArrayI
James (hi! :)
On Fri, Feb 16, 2018 at 12:55 AM, James Roper wrote:
> The question for me then is whether there is value in introducing an
> additional higher level API (ie, a reactive streams based API) for the
> purposes of integration with other libraries that provide RS support.
I have mixed
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
Hi,
On Mon, Feb 19, 2018 at 10:55 PM, Chuck Davis wrote:
>> Note also that your requirement is to use blocking, stream-based,
>> byte[]-based APIs.
>> If you had chosen a data format for which a non-blocking parser based
>> on ByteBuffer APIs existed, you would be so happy about the JDK 9
>> APIs
If it's a question of resources for building a separate Flow based API on
top of the existing API provided, then perhaps we could help? I could
certainly implement it outside the JDK in the coming months, would the HTTP
client team be willing to consider folding it in as a utility alongside the
Web
Hi Daniel,
Thank you for your comment.
Dispatcher is package-private class and handle method is called at
only this file in the package (sun.net.httpserver), and all call sites
look like to handle exception suitably. So we can remove `throws
IOException` clause without modifying the call site log
On 19/02/2018 20:19, Simone Bordet wrote:
:
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).
There is
10 matches
Mail list logo
