views:

146

answers:

2

When refactoring methods it is easy to introduce binary incompabilities (with previous versions of the code) in Java.

Consider changing a method to widen the type of its parameter to a parent interface:

 void doSomething(String x);

 // change it to

 void doSomething(CharSequence c);

All the code that uses this method will continue to compile without changes, but it does require a re-compile (because the old binaries will fail with a MethodNotFoundError).

How about pulling a method up into a parent class. Will this require a re-compile?

// before
public class B extends A{
    protected void x(){};
}

// after
public class A {
    public void x(){};
}
public class B extends A{}

The method has been moved from B to the parent A. It has also changed visibility from protected to public (but that is not a problem).

Do I need to maintain a "binary compatibility wrapper" in B, or will it continue to work (automatically dispatch to the parent class)?

 // do I need this ?
 public class B extends A{
     // binary compatibility wrapper
     public void x(){ super.x(); }
 }
+1  A: 

It should continue to work automatically as Java has dynamic linking

Sam
I thought the same thing about the widened methods... That does not work because the class names of the arguments become part of the internal method name. I wonder if the same holds true with the name of the class that the compiler thinks declares the method.
Thilo
"Widening" affects the signature of the method, but moving the method to a superclass does not. Try it out on the commandline.
bkail
@bkail: make that an answer, so that I can vote it up.
Thilo
There are details of binary compatibility in the JLS.
Tom Hawtin - tackline
+2  A: 

"Widening" affects the signature of the method so that is not binary compatible. Moving a method to a superclass does not affect the method signature, so it will work. Eclipse has a great document that describes API and ABI compatibility:

http://wiki.eclipse.org/Evolving%5FJava-based%5FAPIs

More explicit rules are in part 2:

http://wiki.eclipse.org/Evolving%5FJava-based%5FAPIs%5F2

I believe you're interested in "Change type of a formal parameter" (i.e., what you refer to as widening) or "Move API method up type hierarchy" (i.e., what you refer to as pull into a parent class).

bkail