1. Reading from pipes out of data
If a pipe runs out of data should it block on a read or return -1?
Currently an empty pipe blocks on read and returns -1 only when closed.
People certainly expect socket reads to block waiting for data but it
doesn't really happen with files, and a file returns -1 at end of file
even though the file could be extended.

2. Repeatedly calling select without processing channels
If you register a channel for OP_WRITE after connecting, and repeatedly call
select(), should the select immediately return each time even though
the channel is not processed and the ready key set is undisturbed?
On Solaris the select call returns any number of times but on Windows
it will only report the channel ready once.

3. The spec should note that receiving from unbound DatagramChannels
   will always return null.

4. Read and write operations should require that if any bytes are transferred
   then an exception will not be thrown (4796219).

5. The spec should say what happens when a DatagramChannel invokes send with a null target or a target that doesn't match what it is connected to

6. Do the cases where a Selector can spin require any spec changes?
> >1. The channel was not connected, the key interested in writing and
> > the key ready for writing. Because the key is ready for something it
> > is interested in, the select operation returns immediately, but the
> > key is not marked as ready for write, because the channel is not
> > in the connected state, therefore the key was not added to the selected
> > set. So the selector spins and returns 0.
> >
> Are you saying this is not a bug in nio? If so, there seems to be a
> subtle undocumented relationship
> between OP_WRITE and OP_CONNECT.
> At the OS level "writability" implies "connected" and is documented as
> such, but it seems as if NIO
> wants apps to wait for OP_CONNECT before checking OP_WRITE, but this is
> not specified
> and therefore cannot be enforced.
>
> Would it not make more sense to specify this behavior and throw an
> exception if someone calls
> select with OP_WRITE before the socket is connected? That way,
> developers would recognise the
> problem much sooner, rather than :-
> - noticing a strange performance problem,
> - diagnosing that the selector is spinning
> - then filing a nio bug in frustration.
>
> Alternatively, the docs for SelectionKey should spell this out in more
> detail.
> >
> >2. The channel was connected, the key interested in connecting and
> > the key ready for connecting. Because the key is ready for something it
> > is interested in, the select operation returns immediately, but the
> > key is not marked as ready to connect, because the channel is already
> > connected. Therefore the key was not added to the selected set, the
> > selector spins and returns 0.