AsynchrronousByteChannel vsAsynchronousFileChannelandAsynchronousTransmitter

[Alexander Libman]

Alan, 
I just realized that the idea to allow the developer to specify  how many
default positions is not good :

> > >   
> > I don't have a strong opinion on this except to say that different 
> > global positions for reading and writing is likely to be a surprise to 
> > many developers.
> 
> There is an "intermediate" solution:
>   static AsynchronousByteChannel newChannel(AsynchronousFileChannel ch,
>                                             boolean twoOrOnePositions) 
> 
>So the developer can choose the behavior he wants.


If one channel has been created with one position and the other with two positions,
then single user of those channels will not know what the behavior to expect.

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?

Seems such modification of hierarchy of interfaces should not impact on compliation and
build of existing NIO2.
And it will give more flexibility in developing "pseudo-asynchrnous" objects like
Async. Filters, Transmitters,Converters, Decoders, Encoders, etc....

Example :
interface AsynchronousCharChannel
    extends AsynchronousReadable<CharBuffer,Integer>,
            AsynchronousWritable<CharBuffer,Integer>
{
   
}   


Alex