AsynchrronousByteChannelvsAsynchronousFileChannelandAsynchronousTransmitter

[Alan Bateman]

Alexander Libman wrote:
> Alan,
>
>   
>> 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.
>>     
>
> Yes. Similar the ReadableByteChannel can be defined as
>
> interface ReadableChannel<TYPE>  {
>    int     read(TYPE dst);
> }
>
> interface ReadableByteChannel
>    extends ReadableChannel<ByteBuffer> ,
>            Channel,
>            Closeable {
> }
>
> interface Readable
>    extends ReadableChannel<CharBuffer> {
> }
>
>
> interface ScatteringChannel<TYPE>  {
>    long   read(TYPE [] dst)
>    long   read(TYPE [] dst, int offset, int length)
> }
>
> interface ScatteringByteChannel
>    extends ScatteringChannel<ByteBuffer>
>            Channel,
>            Closeable {
> }
>
> Same for GatheringChannels...
>
> I see that such modification does not break any existing code.
>
>   
>> 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.
>>     
>
> yes, this would be great and extend a scope of application of asynchronous
> pattern
> a lot.
>
>
>   
>> 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> { .. }
>>     
>
>
> Yes, this does not work.
> I did not assume that AsynchronousSocketChannel
> should implement AsynchronousIOChannel<ByteBuffer[],Long>
> I assumed the inheritance from AsynchronousByteChannel only.
>
> But you made next step to :
>
> interface AsynchronousScatteringChannel<TYPE>
>    extends AsynchronousReadableChannel<TYPE> {
>
>     <A> Future<Long>  read(TYPE[] dst,
>                            int    offset,
>                            int    length ,
>                            A attachment,
>                            CompletionHandler<Long,? super A> handler);
> }
>
> interface AsynchronousGatheringChannel<TYPE>
>    extends AsynchronousWritableChannel<TYPE> {
>
>     <A> Future<Long>  write(TYPE[] dst,
>                            int    offset,
>                            int    length ,
>                            A attachment,
>                            CompletionHandler<Long,? super A> handler);
> }
>
> interface AsynchronousScatteringGatheringChannel<TYPE>
>     extends AsynchronousScatteringChannel<TYPE>,
>             AsynchronousGatheringChannel<TYPE> {
> }
>
>
> Having such interfaces, we can produce
>
> class AsynchronousSocketChannel
>  implements AsynchronousByteChannel,
>    AsynchronousScatteringGatheringChannel<ByteBuffer> {
>
>     ...
> }
>
> this should work.
> Disadvantage too many interfaces, advantage - flexibility.
>
> Currently, we can develop filters only for the Inner->Outer pair:
>    AsynchronousByteChannel -> AsynchronousByteChannel
>
> To develop identical filters for "outer channel" with CharBuffer
> instead of ByteBuffer , for example,
> it is required to introduce kind  of AsynchronousIOChannel<TYPE> interface.
> If this interface would be unrelared to AsynchronousByteChannel, then
> the same filter can be duplicated for two cases:
>    AsynchronousByteChannel -> AsynchronousIOChannel<TYPE>
> and
>    AsynchronousIOChannel<ByteBuffer> -> AsynchronousIOChannel<TYPE>
>
> And the filter code would be exactly the same (no difference at all).
>
> Probably, there is a workaround to avoid code duplication via wrapper
> class Wrapper {
>    static AsynchronousIOChannel<ByteBuffer> wrap(
>                                   AsynchronousByteChannel channel)
> }
>
> In both cases:
>
> a) AsynchronousIOChannel<ByteBuffer> is a base for AsynchronousByteChannel
> or
> b) wrapper solution
>
> all filters stuff can be converted to work with AsynchronousIOChannel<>
> to provide generic solution:
>    AsynchronousIOChannel<TYPE1> -> AsynchronousIOChannel<TYPE2>
>
> What is better a) or b)  I do not know yet.
> Alex
>   
The channels package needs to stayed focused on file and network I/O. 
While interfaces to facilitate higher level asynchronous operations are 
nice, they probably should be in a higher level framework or other 
layered API.  Adding asynchronous forms of ReadableByteChannel and 
WritableByteChannel, as per my previous mail, is fine because they are 
generally useful for things such as adapters and decorating (and we can 
make use of this in the Channels class for example). It would mean that 
your AsynchronousIOChannel would need to be created to wrap an 
AsynchronousByteChannel [option (b)].  Does that seem reasonable?

-Alan.