AsynchronousSocketChannel still throws unspecified exception (original) (raw)
cowwoc cowwoc at bbs.darktech.org
Wed Jul 6 06:55:57 PDT 2011
- Previous message: AsynchronousSocketChannel still throws unspecified exception
- Next message: AsynchronousSocketChannel still throws unspecified exception
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
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.MAXVALUE 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:
- Ask the channel to return whatever data it has without waiting
- 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.
- Previous message: AsynchronousSocketChannel still throws unspecified exception
- Next message: AsynchronousSocketChannel still throws unspecified exception
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]