Métodos refactorizados y compatibilidad binaria en Java

Question

Cuando se refactorizan los métodos, es fácil introducir incompabilities binarias (con versiones anteriores del código) en Java.

considerar el cambio de un método para ampliar el tipo de su parámetro a una interfaz de padres:

void doSomething(String x); 

// change it to 

void doSomething(CharSequence c); 

Todo el código que utiliza este método seguirá compilará sin cambios, pero sí requiere una re-compilación (porque los binarios antiguos fallarán con un MethodNotFoundError).

¿Qué hay de tirar de un método en una clase para padres. ¿Esto requerirá una nueva compilación?

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

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

El método ha sido movido de B a la A. matriz También ha cambiado la visibilidad de protección al público (pero eso no es un problema).

¿Necesito mantener un "contenedor de compatibilidad binaria" en B, o continuará funcionando (se enviará automáticamente a la clase principal)?

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

Answer 1

"Ampliación" afecta a la firma del método de manera que no es compatible a nivel binario. Mover un método a una superclase no afecta la firma del método, por lo que funcionará. Eclipse tiene un gran documento que describe la API y la compatibilidad ABI:

http://wiki.eclipse.org/Evolving_Java-based_APIs

normas más explícitas están en la parte 2:

http://wiki.eclipse.org/Evolving_Java-based_APIs_2

Creo que usted está interesado en "cambiar el tipo de un parámetro formal "(es decir, lo que se refiere a la ampliación) o" Mover la jerarquía de tipos de método API "(es decir, lo que se denomina extracción en una clase principal).

Answer 2

Se debe seguir trabajando de forma automática como Java tiene vinculación dinámica