The conversation has gone a little off topic from the WebSocket API, and this is probably not the best place to be discussing such proposed convenience / performance APIs, since they need broader discussion than net-dev.
It seems most folk are in agreement that the proposed WebSocket API could be used as a foundation to build the desired higher-level abstractions that have been asked for on this thread. I see this as a win for the proposed low-level Java SE WebSocket API. It is supposed to be a building block, not a complete building. -Chris. > On 20 Feb 2018, at 10:52, Simone Bordet <simone.bor...@gmail.com> wrote: > > Hi, > > On Tue, Feb 20, 2018 at 10:22 AM, Alan Bateman <alan.bate...@oracle.com> > wrote: >> >> >> On 20/02/2018 08:14, Simone Bordet wrote: >>> >>> : >>> Where would be a good list to start discussing ByteBuffer to >>> [Input|Output]Stream bridging ? >>> >> Are you looking for this for performance or convenience reasons? > > Convenience. > >> Bridging channel and input/output streams is natural of course, bridging >> between >> buffers and input/output streams hasn't come up very often. ByteBuffer >> defines bulk get/put methods so it's trivial for anyone to wrap byte buffers >> if they need to. > > Sure, it just would be handy the JDK provided this rather than users > rewriting the same utility class. > > For example, having: > > OutputStream.write(ByteBuffer) > InputStream.read(ByteBuffer) > > avoiding intermediate copies to byte[] but also: > > ByteBufferInputStream.offer(ByteBuffer b, boolean last) > > to feed ByteBuffers to the InputStream and be able to read them via > normal byte[]. > > Something along these lines. > > Thanks ! > > -- > Simone Bordet > --- > Finally, no matter how good the architecture and design are, > to deliver bug-free software with optimal performance and reliability, > the implementation technique must be flawless. Victoria Livschitz
