AsynchrronousByteChannel vsAsynchronousFileChannelandAsynchronousTransmitter

[Alan Bateman]

Alexander Libman wrote:
> :
> Thinking about topic:
> In general, we can consider AsynchronousByteChannel as two independent streams:
> read stream and write stream. From this point of view -  having two default positions seems reasonable.
> These positions are never exposed to the user. Once we have created AsynchronousByteChannel,
> we can forget that we work with file. We deal only with sequential reads and writes.
> The user of this channel does know about implementation, from his point of view
> the next read operation should not depend on performed writes.
>
> May be  the discussion about "defaultPositions" is not important now,
> but it gives me the following idea:
>
>
> interface AsynchronousReadable<BUFFER,RESULT>
>     extends AsynchronousChannel
> {
>     <A> Future<RESULT> read(BUFFER buffer,
>                              A attachment,
>                              CompletionHandler<RESULT,? super A> handler);
> }
>
> interface AsynchronousWritable<BUFFER,RESULT>
>     extends AsynchronousChannel
> {
>     <A> Future<RESULT> write(BUFFER buffer,
>                              A attachment,
>                              CompletionHandler<RESULT,? super A> handler);
> }
>
> interface AsynchronousByteChannel
>     extends AsynchronousReadable<ByteBuffer,Integer>,
>             AsynchronousWritable<ByteBuffer,Integer>
> {
>    
> }   
>
> What you think? Is it too late? Will it impact on performance?
>   
Right, defining readable and writable interfaces is probably the right 
thing to do, and they can be unified by AsynchronousByteChannel (like 
ByteChannel unified the synchronous interfaces). It has come up once or 
twice but there hasn't been a big need so far. Your proposal is a bit 
more general that you have introduced type parameters for the buffer and 
result types. It's worth looking at but would be a bit inconsistent with 
the existing interfaces and of course this package is only does I/O on 
byte buffers. So don't let me put off, this area is worth exploring and 
your filters and other composite operations could make for a useful toolkit.

-Alan.