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

Joe Bowbeer joe.bowbeer at gmail.com
Tue Nov 1 18:32:39 EST 2005


Adding a return type to a void method would create two incompatibilities:

1. Existing callers of Object.wait would not pop the newly returned value.

2. Existing importers of Object.wait would fail to locate the method.

See Method Descriptors and Return Descriptors in the class file doc:

http://java.sun.com/docs/books/vmspec/2nd-edition/html/ClassFile.doc.html
*
*
On 11/1/05, Jason Mehrens <jason_mehrens at hotmail.com> wrote:
>
> 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
>
> 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 (adding a new method to Object is a
> different story). The method has a void return type so no caller is
> looking
> at the return value, there is none. The method is final so no subclass or
> interface has to deal with return type change because it can't override
> method. Existing code does care what the return type because it doesn't
> access it.
>
> Reflection is the only thing I can think of that might break if the code
> is
> explicitly checking the return type of Object.wait(long) and taking a
> different code path if it is not void. Since everything is an "Object" why
> would use reflection to call wait? Maybe an introspection tool would look
> at the return type but I doubt it would cause tool from working.
>
> Jason Mehrens
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: /pipermail/attachments/20051101/aa0d2213/attachment.htm


More information about the Concurrency-interest mailing list