For tracking purposes :-

1. java.nio.channels.Channels provides support for interoperation of
stream classes with channels classes. However there may be concurrency
as both Channels.newInputStream(sc).read() and
Channels.newOutputStream(sc).write() synchronize on the blockingLock.
Thus a thread blocked on read will cause another thread wishing to
write to block.

2. As a SocketChannel is a ReadableByteChannel it may be worth
updating the specification of Channels.newInputStream to indicate
that the reads on the InputStream do not timeout if
sc.socket().setSoTimeout() is called to specify a
timeout (or maybe there should timeout?).

3. Similiar to item 1 the new SocketAdaptor prohibits concurrent
reader & writes threads -- eg: thread blocked on
sc.socket().getInputStream().read() will cause another thread
to block in sc.socket().getOutputStream().write(). The issue
gets a more complicated with read timeouts as the channel is
temporarily put into non-blocking mode to support the timeout.
Thus if the blockingLock issue is resolved we need to ensure
that 'write' supports the blocking semantics irrespective of
the blocking mode of the channel.