Object.wait(long) not returning the time remaining.

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Object.wait(long) not returning the time remaining.

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


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Object.wait(long) not returning the time remaining.

Joe Bowbeer
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 <[hidden email]> 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



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

RE: Object.wait(long) not returning the timeremaining.

David Holmes
In reply to this post by Jason Mehrens
Jason,

> 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:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4027382

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
valid.

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

Cheers,
David Holmes

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|

Re: Object.wait(long) not returning the time remaining.

Brian Goetz
In reply to this post by Jason Mehrens
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.

Example:

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();
     f.setI(1);
     f.setAndGetI(1);
   }
}

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
change.

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

public int setAndGetI(int);
   Code:
    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();
   Code:
    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

_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://altair.cs.oswego.edu/mailman/listinfo/concurrency-interest