Async channels

[Alan Bateman]

Rémi Forax wrote:
> :
> That why I prefer the semantics of getSocketRemoteAddress(), because 
> you know that
> this is just a getter without native calls behind.
> Anyway, you're the boss.
The getSocketRemoteAddress semantics is that it requires the 
implementation to get and cache the remote address before the socket is 
closed. It is more efficient to only retrieve it if required. 
Furthermore, all I/O methods in the channels package throw 
ClosedChannelException when invoked on a closed channel so we would be 
introducing an small inconsistency. Aside from possible logging, I 
cannot think of cases where the remote address is useful after it is no 
longer valid.

>
> Ok, so the doc for completion handler can be enhanced to says that the 
> Throwable (why not use Exception instead, btw)
> is the common super type of IOException and SecurityException.
It could for the current usage although we do use it to propagate 
internal errors [should never happen :-) ]. Keeping it as Throwable does 
provide for some flexibility if used for other purposes and usages in 
the future.


>
> Crawling the web, I have found that Kevents dev was closed,
> without a replacement of the mechanism to get AIO notification :)
As I said, the API is mappable to quite a range of I/O facilities so we 
can re-target as required if a better mechanism becomes available (we've 
done that a few times with Selector too, like it was originally poll on 
Linux but we switched to epoll).

-Alan.