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

Brian Goetz brian at quiotix.com
Tue Nov 1 19:05:24 EST 2005

What you describe is source compatibility, not binary compatibility. 
Changing the return type from void to non-void will not break any 
_source_ code that uses it.  But it will break bytecode, since the 
return value has to be popped off the stack if it is ignored.


class Foo {
   int i;
   public void setI(int arg) { i = arg; }
   public int setAndGetI(int arg) { i = arg; return i; }

   public static void main() {
     Foo f = new foo();

Look at the bytecode below.  Notice the extra 'pop' in the call to 
setAndGetI where the return value is ignored.  Existing bytecode which 
calls Object.wait() would not have that, so it is not a binary compatble 

public void setI(int);
    0:	aload_0
    1:	iload_1
    2:	putfield	#2; //Field i:I
    5:	return

public int setAndGetI(int);
    0:	aload_0
    1:	iload_1
    2:	putfield	#2; //Field i:I
    5:	aload_0
    6:	getfield	#2; //Field i:I
    9:	ireturn

public static void main();
    0:	new	#3; //class Foo
    3:	dup
    4:	invokespecial	#4; //Method "<init>":()V
    7:	astore_0
    8:	aload_0
    9:	iconst_1
    10:	invokevirtual	#5; //Method setI:(I)V
    13:	aload_0
    14:	iconst_1
    15:	invokevirtual	#6; //Method setAndGetI:(I)I
    18:	pop
    19:	return


Jason Mehrens 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

More information about the Concurrency-interest mailing list