AsynchrronousByteChannel vsAsynchronousFileChannelandAsynchronousTransmitter

[Alan Bateman]

libman at terabit.com.au wrote:
> Alan,
>
>   
>> 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.
>>
>>     
>
> I do not see any inconsistense with existing interfaces
> Assume we have imaginable:
>
> interface AsynchronousIOChannel<PARAMETER,RESULT>
>     extends AsynchronousChannel
> {
>     <A> Future<RESULT> read(PARAMETER buffer,
>                              A attachment,
>                              CompletionHandler<RESULT,? super A> handler);
>
>     <A> Future<RESULT> write(PARAMETER buffer,
>                              A attachment,
>                              CompletionHandler<RESULT,? super A> handler);
> }
>
> It may extends imaginable AsynchronousReadable<> and
> AsynchronousWritable<>, but we skip such details for now.
>
> Existing AsynchronousByteChannel can be defined as
> specialization of genereric AsynchronousIOChannel.
> It should not work with any other types of PARAMETERs
> except only ByteBuffer.
>
> interface AsynchronousByteChannel
>     extends AsynchronousIOChannel<ByteBuffer,Integer>
> {
> }
>
> We simply insert into hierarchy of interfaces additional generic
> interface. All existing code of NIO2 will compile and work without any
> changes.
>   
Sorry, I wasn't very clear. The inconsistency that I was thinking about 
relates to the existing ReadableByteChannel and WritableByteChannel 
interfaces as they aren't parameterized. The asynchronous equivalents of 
the existing interfaces would be:

    interface AsynchronousReadableByteChannel extends AsynchronousChannel {
        Future<Integer> read(ByteBuffer dst);
        <A> void read(ByteBuffer dst, A attachment, 
CompletionHandler<Integer,? super A> handler);
    }

    interface AsynchronousWritableByteChannel extends AsynchronousChannel {
        Future<Integer> write(ByteBuffer src);
        <A> void write(ByteBuffer src, A attachment, 
CompletionHandler<Integer,? super A> handler);
    }

    interface AsynchronousByteChannel extends
        AsynchronousReadableByteChannel, AsynchronousWritableByteChannel { }

It's come up a few times that we should add 
AsynchronousReadableByteChannel and AsynchronousWritableByteChannel but 
there hasn't been a great need to date. Such interfaces would improve 
the adapter methods in the Channels class and would also solve the 
wrapping of AsynchronousFileChannel that you run into.

Anyway, your proposes interfaces go further by adding type parameters so 
it could have wider use outside of the channels package (would be great 
for the filter work). I think this is worth looking at but I don't know 
how it would work with scatter/gather operations (or channel types that 
support reading.writing with other buffer types). For example, I don't 
think this will work:

class AsynchronousSocketChannel
  implements AsynchronousByteChannel, 
AsynchronousIOChannel<ByteBuffer[],Long> { .. }

because it would be attempting to implement the same interface with 
different parameters.

-Alan.