Async channels

[Alan Bateman]

Rémi Forax wrote:
> Hi Alan, hi all,
> I have some questions about channels and their implementations.
> (I use the jdk7 workspace so sorry if it's already fixed).
>
> 1) Why 
> SocketChannel.getRemoteAddress()/Async...Channel.getRemoteAddress()
>    and Socket.getSocketRemoteAddress() doesn't have the same semantics ?
>
>   getSocketRemoteAddress() returns the remote address even
>   if the connection is closed,
>   getRemoteAddress() throws a IOException in that case.
The getRemoteAddress method throws ClosedChannelException if invoked on 
a closed channel. The reason for the IOException is to allow an 
implementation retrieve the address only when required. 
Socket#getSocketRemoteAddress, on the other hand, didn't originally 
specify this case. There were a bunch of other "close socket" cases in 
the java.net package that were also undefined. Early in jdk7 the javadoc 
was updated to fix these up these cases; existing behavior had to be 
specified to avoid breaking code that may have been relying on it.

>
> 2) In the doc of AsynchronousChannel there is a small typo:
>    <li><pre>Future&lt;V&gt; <em>operation</em>(<em>...</em> A attachment,
>    {@link CompletionHandler}&lt;V,? super A&gt handler)</pre></li>
>    should be
>    <li><pre>Future&lt;V&gt; <em>operation</em>(<em>...</em> A attachment,
>    {@link CompletionHandler}&lt;V,? super A&gt; handler)</pre></li>
>                             a semicolon is missing here   -----^
Thanks.

>
> 3) The doc of AsynchronousChannel is not crystal clear for methods
>     read() or write() that doesn't take a completion handler
>     in case of IOException.
>
>     "In the first form, the methods defined by the {@link Future Future}
>      interface may be used to check if the operation has completed, 
> wait for its
>      completion, and to retrieve the result."
>
>     Is future.get() will throw a ExecutionException that will wrap the 
> corresponding
>     IOException ?
Yes, it will wrap the IOException (or maybe SecurityException in some 
cases). I've made a note to myself to see if this can be made clearer.

>
> 4) Why CompletionHandler.failed() take a Throwable and not a 
> IOException ?
It may be something other than IOException. The accept and receive 
operations for example may fail with a SecurityException for example.

>
> 5) As specified in the doc of AsynchronousChannel about cancelation,
>    "further attempts to initiate a {@code read} operation causes an
>      unspecified runtime exception to be thrown".
>   Why a runtime exception and not a call to the completion handler ?
Yes, this bug can be caught before the I/O operation is initiated so the 
IllegalStateException or other runtime exception can be thrown then.

>
> 6) Is it possible to rename all Asynchronous* to Async*.
>    I will *really* increase the readability of the types.
This package doesn't use abbreviations in class names. Okay, the new 
channels have longish class names but no big deal.

>
> 7) UnixAsynchronousSocketChannelImpl.onCancel() seems to have a 
> copy&paste bug:
>
> public void onCancel(PendingFuture<?,?> task) {
>        if (task.getContext() == OpType.CONNECT)
>            killConnect();
>        if (task.getContext() == OpType.READ)
>            killConnect();    // <----------------------- killReading()
>        if (task.getContext() == OpType.WRITE)
>            killConnect();   // <----------------------- killWriting()
>    }
Thanks; amazingly this this bug doesn't have much impact.

>
>
> 8) Why AsyncFileChannel.open(...) take an ExecutorService and not a 
> AsyncChannelGroup ?
File I/O is very different to socket I/O and it may not be feasible for 
an implementation to share resources or thread pools between file and 
network oriented channels. Think of an AsynchronousFileChannel as a 
group of one containing one channel. The exception is when you use the 
simpler open method as that will use the thread pool associated with the 
default group.

-Alan.