AsynchrronousByteChannelvsAsynchronousFileChannelandAsynchronousTransmitter

[Alexander Libman]

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