AsynchronousSocketChannel still throws unspecified exception

[cowwoc]

cowwoc wrote:
> 
> 
> Alan Bateman-2 wrote:
>> 
>> cowwoc wrote:
>>> :
>>> Also, I think you should push very hard to get this fixed in JDK7. I'd
>>> be
>>> very surprised if Oracle lets you change this part of the specification
>>> in
>>> JDK8 because doing so would break backwards-compatibility for existing
>>> implementations. Better to fix it now before the final spec is
>>> published.
>>>
>>>   
>> I've created this bug to track it:
>> 
>> 7054403: (aio spec) IllegalStateExcepiton should be thrown if I/O 
>> operation attempted after timeout
>> 
>> It's unfortunate that this got forgotten but I think we can fix this 
>> early in jdk8. It helps that the current implementation already throws 
>> IllegalStateException. Furthermore, AsynchronousSocketChannel cannot be 
>> implemented in isolation as it is tied to an 
>> AsynchronousChannelProvider. This means the number of implementations 
>> will likely be very few. Again apologies about this, it was my fault 
>> that this got forgotten.
>> 
>> -Alan.
>> 
> 
> Now I'm getting really worried... I just noticed that socket timeouts are
> wrong as well!
> 
> If you recall, we had agreed that a timeout value of 0 or less should mean
> "no timeout" and Long.MAX_VALUE should mean "wait forever":
> http://web.archiveorange.com/archive/v/gpYtBv5dfSke8QjCflUY
> 
> But according to
> http://download.oracle.com/javase/7/docs/api/java/nio/channels/AsynchronousSocketChannel.html
> "All methods that accept timeout parameters treat values less than or
> equal to zero to mean that the I/O operation does not timeout."
> 
> I'm especially worried that unless we fix this in JDK7 it will be
> impossible to do so in JDK8 due to backwards compatibility concerns.
> Please say you can fix this in time for JDK7!
> 
> Thanks,
> Gili
> 

Alan,

I've filed http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7063249

Another two reasons I believe this must be fixed is that the existing
specification makes it impossible to:

1. Ask the channel to return whatever data it has without waiting
2. As a consequence of #1, you can't ask the channel if it's in an error
state without reading at least one byte

As you said two years ago, "It's a pity we can't do anything with the
existing APIs." I really hope we don't have to say the same about
AsynchronousSocketChannel a few years from now...

Kind Regards,
Gili

--
View this message in context: http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6554472.html
Sent from the nio-dev mailing list archive at Nabble.com.