Refaktoryzowane metody i kompatybilność binarna w Javie

Question

Podczas refaktoryzacji metod łatwo jest wprowadzić nieporozumienia binarne (z wcześniejszymi wersjami kodu) w Javie.

Rozważ zmianę metody do poszerzenia typu jej parametr do interfejsu nadrzędnego:

void doSomething(String x); 

// change it to 

void doSomething(CharSequence c); 

Cały kod, który korzysta z tej metody będzie nadal skompilować bez zmian, ale wymaga ponownej kompilacji (ponieważ stare pliki binarne zawiedzie z MethodNotFoundError).

Co powiecie na przeciągnięcie metody do klasy rodzica. Czy będzie to wymagało ponownego skompilowania?

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

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

Metoda została przeniesiona z B do rodzica A. Zmieniono także widoczność z chronionej na publiczną (ale to nie jest problem).

Czy muszę zachować "opakowanie binarne" w B, czy będzie ono nadal działać (automatycznie wysyłane do klasy nadrzędnej)?

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

Answer 1

„Rozszerzenie” wpływa na podpis metody, tak że nie jest binarnie kompatybilny. Przeniesienie metody do nadklasy nie wpływa na sygnaturę metody, więc będzie działać. Eclipse ma świetny dokument, który opisuje API i ABI kompatybilność:

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

Bardziej wyraźne zasady są w części 2:

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

wierzę, że jesteś zainteresowany w „Zmień typ parametr formalny "(tzn. co się nazywa rozszerzaniem) lub" Move API method up hierarchy typu "(tzn. co określa się jako wciągnięcie do klasy rodzica).

Answer 2

Należy nadal pracować automatycznie jako Java ma dynamiczne łączenie