[concurrency-interest] Object.wait(long) not returning the timeremaining.

David Holmes dholmes at dltech.com.au
Tue Nov 1 18:33:46 EST 2005


> This might be off topic but, can someone clarify the evaluation of RFE
> 6176773 to me? Here is the link:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6176773

I'm surprised they even accepted the above as a RFE. This was killed off
long long ago - see:

This could have been fixed in 1997 one way or another but they didn't see
that. Ancient history now.

> The evaluator states: "The actual signature of Object.wait can never be
> changed, because of binary
> compatibility."  I don't see how changing the return type of a final void
> method can break binary compatibility

It breaks binary compatibility because the JLS (Chapter 13) says that it
does. Changing the return type of a method has the effect of deleting the
old method and adding a new one. The former change is not binary compatible
if a method with the same signature and return type does not exist in a
superclass of the class being changed. While at the language level it would
seem a harmless change, at the JVM level the return type is part of the
method descriptor used by the bytecode - hence changing the return type
would result in a runtime error due to a missing method.

Unless you are trying to use wait() for doing explicit timing (which you
should not be doing) then this lack of information is not critical. The
important thing is whether or not the condition you were waiting on is now

If you really need to know then use the new Condition objects and their
awaitNanos method.

David Holmes

More information about the Concurrency-interest mailing list