JDK-6176773 : Object.wait(long) should return a long not a void
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 5.0
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2004-10-11
  • Updated: 2017-08-11
  • Resolved: 2006-08-01
Related Reports
Relates :  
Description
A DESCRIPTION OF THE REQUEST :
Allow Object.wait(long) to return a long value. Doing so will permit the developer to determine whether or not the return from the wait was from a notify() call by some other thread or by the wait's timeout. Wait(long) will return a long value greater than 0 when a notify() has occured. It will return a 0 when the wait has timed out.

JUSTIFICATION :
See Description

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
long l;
while (true) {
   //...
   l = wait(60000);
   if (l > 0) {
       // wait timed out
       break;
   }
    // notify occured
}

// exit gracefully
ACTUAL -
        long then;
        long now;
while (true) {
   //...
   then = (new java.util.Date()).getTime();
   wait(decay);
   now = (new java.util.Date()).getTime();
   if (now - then - decay >= 0) {
       break; // exit gracefully
   }
    // notify occured
}

// exit gracefully

---------- BEGIN SOURCE ----------
see above
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
see above
###@###.### 10/11/04 04:57 GMT

Comments
EVALUATION The new replacements for builtin Java monitors in java.util.concurrent, for example Condition.await, return a boolean indicating whether the timeout expired. User code can be rewritten to use these new classes. Class Object can no longer be changed.
01-08-2006

EVALUATION The actual signature of Object.wait can never be changed, because of binary compatibility. Still, it would be good if a user can determine the cause of a return from Object.wait(long). If the thread is interrupted, an InterruptedException is thrown, so this case is clear. The other causes of return from the call are notification, timeout, and spurious wakeups. Because applications must take into account spurious wakeups, they must, in practice follow the advice of Object.wait(long): A thread can also wake up without being notified, interrupted, or timing out, a so-called spurious wakeup. While this will rarely occur in practice, applications must guard against it by testing for the condition that should have caused the thread to be awakened, and continuing to wait if the condition is not satisfied. In other words, waits should always occur in loops, like this one: synchronized (obj) { while (<condition does not hold>) obj.wait(timeout); ... // Perform action appropriate to condition } Probably this will be closed as Will Not Fix. If spurious wakeups cannot be eliminated, then an accurate reason for the wakeup can also probably not be returned. ###@###.### 10/11/04 22:31 GMT
11-10-2004