Metodi refactoring e compatibilità binaria in Java

Question

Durante i metodi di refactoring è facile introdurre le inabilità binarie (con versioni precedenti del codice) in Java.

pensare di cambiare un metodo per ampliare il tipo del suo parametro ad un interfaccia madre:

void doSomething(String x); 

// change it to 

void doSomething(CharSequence c); 

Tutto il codice che utilizza questo metodo continuerà a compilare senza modifiche, ma richiede un re-compile (perché i vecchi binari falliscono con un metodo MethodNotFoundError).

Che ne dici di inserire un metodo in una classe padre. Ciò richiederà una ricompilazione?

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

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

Il metodo è stato spostato dalla B alla A. genitore Ha anche cambiato la visibilità da protetto al pubblico (ma che non è un problema).

Devo mantenere un "wrapper di compatibilità binaria" in B, o continuerà a funzionare (invio automatico alla classe genitore)?

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

Answer 1

"Ampliamento" colpisce la firma del metodo in modo che non è compatibile a livello binario. Lo spostamento di un metodo in una superclasse non influisce sulla firma del metodo, quindi funzionerà. Eclipse ha un grande documento che descrive API e la compatibilità ABI:

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

Norme più esplicite sono in parte 2:

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

Credo che sei interessato a "Cambia il tipo di un parametro formale "(vale a dire, ciò a cui si fa riferimento come allargamento) o" Move API method up hierarchy type "(cioè, ciò a cui si fa riferimento come pull in una classe genitore).

Answer 2

Dovrebbe continuare a funzionare automaticamente come Java ha dinamico che collega