Bug #7063249

[cowwoc]

Alan Bateman-2 wrote
> On 18/09/2013 18:17, cowwoc wrote:
>> :
>>
>> Regarding whether timeout<= 0 returning immediately is the right thing to
>> do,
> All these methods return immediately (they aren't synchronous, they 
> never block). The issue that that we did not come to a conclusion was 
> whether there should be API support for having I/O operating that 
> complete immediately when there aren't any bytes transferred.  That 
> needs further consideration to see if it make sense, the API issue is 
> somewhat secondary to that.

Alan,

That's not what I'm saying. What I'm saying is that we already discussed and
agreed to change the API so that "timeout <= 0 should result in the
asynchronous read/write operations completing immediately".

Here is what I've managed to piece together by examining the dates of the
mailing list and bug reports:

1. In
http://mail.openjdk.java.net/pipermail/nio-discuss/2009-June/000240.html
Doug wrote that timeout <= 0 must complete immediately because an API that
does otherwise "can surprisingly misbehave if timeLimit - elapsed happens to
be 0." and "I agree that this should be changed. Any method taking a
TimeUnit should obey j.u.c conventions. Which means separating out the
no-timeout case as another method."

According to
http://docs.oracle.com/javase/7/docs/api/java/util/concurrent/package-summary.html
j.u.c conventions state that timeout "less than or equal to zero to mean not
to wait at all". In other words, timeout <= means the operation should
complete immediately.

What Doug was saying is that the "no-timeout" case (where operations block
forever) should be separated into another method and that the method *with*
a timeout parameter should complete immediately if <= 0. In response, you
wrote: "I'll fix this shortly so that <= 0 means no-timeout".

Doug and I interpreted this as you agreeing but it sounds like you
misunderstood and implemented the exact opposite behavior.

2. Two months later someone filed 6878369 stating that timeout < 0 "do [...]
not have an associated timeout."

Notice the critical mistakes here:

a. This bug report discusses timeout < 0 instead of timeout <= 0
b. Its description is a direct contradiction of what we agreed to in the
mailing list. We agreed that the operation should complete immediately.
Instead, this bug report says that we agreed that the operation should "have
no timeout".

3. Two years later I pulled down the latest JDK7 build (a month before the
release) and noticed that #1 had not been implemented. When I brought it to
your attention in
http://nio-dev.3157472.n2.nabble.com/AsynchronousSocketChannel-still-throws-unspecified-exception-tp6471557p6473226.html
you wrote:

"It's unfortunate that this got forgotten but I think we can fix this early
in jdk8."

I filed 7063249 to make sure this does not get forgotten.

I hope you can understand why this can be frustrating. I repeatedly tried to
steer the API in the right direction and repeatedly it ended up going in the
exact opposite direction. I understand that you are too busy to consider
this issue, but then the question becomes:

1. Who else at Oracle can work with me to get this into JDK8?
2. How do we make sure that this doesn't happen again?

Thank you,
Gili



--
View this message in context: http://nio-dev.3157472.n2.nabble.com/Bug-7063249-tp7575180p7575196.html
Sent from the nio-dev mailing list archive at Nabble.com.