AsynchrronousByteChannel vsAsynchronousFileChannelandAsynchronousTransmitter

[libman at terabit.com.au]

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.

What the advantage can we have from this?
I think it provides flexibility for future extentions of NIO2.
And speaking about filters, we can gain a lot:

abstract class AsynchronousFilter<OUTER_PARAMETER,
                                  OUTER_RESULT,
                                  INNER_PARAMETER,
                                  INNER_RESULT>
    extends AsynchronousIOChannel<OUTER_PARAMETER,OUTER_RESULT>
{
     private AsynchronousIOChannel<INNER_PARAMETER,
                                   INNER_RESULT> innerChannel;

     /* constructor */
     AsynchronousFilter (AsynchronousIOChannel<INNER_PARAMETER,
                                               INNER_RESULT> channel)
     {
        innerChannel = channel;
     }

     ...
}

We now can develop filters for different OUTER and INNER types
and they provide the same style of interface as AsynchronousByteChannel.

The existing filter becomes the particular case of generic
filter and looks like
    AsynchronousFilter<ByterBuffer,Integer,ByteBuffer,Integer>

One straightforward example of generic filter would be AsynchronousCoder,
which reads and decodes data, writes and encodes :

class AsynchronousCoder
    extends  AsynchronousFilter<CharBuffer,
                                Integer,
                                ByteBuffer,
                                Integer>
{
    /*
     * First parameter charset (or charset name as String)
     * The second parameter is super class
     * of AsynchronousByteChannel
     */
    AsynchronousCoder (Charset charset,
         AsynchronousIOChannel<ByteBuffer,Integer> innerChannel);

    /* will read and decode */
    <A> Future<RESULT> read(CharBuffer buffer,
                            A attachment,
                            CompletionHandler<Integer,? super A> handler);

    /* will write and encode */
    <A> Future<RESULT> write(CharBuffer buffer,
                            A attachment,
                            CompletionHandler<Integer,? super A> handler);
}

I looked at the existing AsynchronousFilter code and seems
it be can converted to the generic filter by simple replacement.

AsynchronousCoder is simular to AsynchronousSSL, but the implementation
would be much easier.
AsynchronousSSLChannel was lucky because the outer and inner types
are the same and AsynchronousByteChannel interface works well.

Alex