Java: Wie kann man veraltete Warnungen in abgeleiteten Schnittstellen vermeiden, die veraltete Elemente außer Kraft setzen?

Question

Betrachten Sie die folgende vereinfachte Schnittstelle inheritence Hierarchie:

// Starting point: 
public interface Base { 
    void Foo(); 
} 

public interface Derived extends Base { 
} 

Es ist beabsichtigt, die Foo Methode aus der Base Schnittstelle zum Derived Schnittstelle zu verschieben:

// Desired end-point: 
public interface Base { 
} 

public interface Derived extends Base { 
    void Foo(); 
} 

Um Phase in diesem unterbrechende Änderung, Es ist erwünscht, die Rückwärtskompatibilität der Schnittstelle für einige Zeit beizubehalten.

Dies kann durch Markieren des Verfahrens auf der Base Schnittstelle als @Deprecated erreicht werden:

// Intermediate state: 
public interface Base { 
    /** 
    * @deprecated This method is deprecated as of release X. Derived.Foo should be used instead. 
    */ 
    @Deprecated void Foo(); 
} 

public interface Derived extends Base { 
    void Foo(); 
} 

Wenn ich diesen Code, den ich eine Compiler-Warnung für Derived erhalten kompilieren:

[deprecation] Foo() in der Schnittstelle Base wurde veraltet

Seltsamerweise, wenn ich die @deprecated aus der Dokumentation in Base entfernen (aber die @Deprecated verlassen) diese Warnung verschwindet.

Ist es richtig, dass ich diese Warnung bekomme, und wenn ja, wie kann ich das umgehen?

---

Die Warnung scheint, dass Derived.Foo wird "mit" Base.Foo zu kommunizieren (die veraltet ist). Die einzige Kapazität, in der Derived.Foo die veraltete Version Base.Foo "verwendet", besteht darin, sie zu überschreiben. Das scheint zu sagen, dass es Ihnen nicht erlaubt ist, veraltete Methoden in abgeleiteten Methoden zu überschreiben.

Wenn dies der Fall ist, sollte ich dann Derived mit @SuppressWarnings("deprecation") verzieren, um die Warnung zu unterdrücken?

Answer 1

Ich glaube, Ihre Anforderung ist gültig, ich habe keinen Zweifel, dass das Überschreiben der veralteten Methode der richtige Weg ist.

Ich glaube, der Unterschied zwischen @deprecated und @Deprecated ist hauptsächlich historisch. @Deprecated ist der offizielle Weg in Java 5, aber ist neu, also wird erwartet, dass wir es mit @deprecated verdoppeln.

Beachten Sie außerdem, dass @Deprecated leider keine Informationen angeben kann. Informationen werden normalerweise benötigt, um beispielsweise anzugeben, was als Ersatz verwendet werden soll oder wann die veraltete Methode vollständig ausgeführt werden soll entfernt.

Nicht mehr zu wissen, und das Problem wird verschwinden, sobald Sie die Super-Methode effektiv entfernen, würde ich die @SuppressWarnings ("Deprecation") verwenden, möglicherweise mit einem Kommentar für Ihre Nachfolger zu verstehen ... (und ein weiterer Kommentar zur super-Methode, um ihnen zu sagen, dass sie alles löschen sollen, wenn sie die Methode löschen.;-)

Answer 2

Wenn ich das richtig verstehe, benötigen Sie am Anfang Ihrer Klassen ein @SuppressWarnings ("deprecation"), das die veraltete Schnittstelle/Funktion implementiert. Oder bin ich weit weg von der Basis?

Answer 3

Es gibt keine Möglichkeit zu erreichen, was Sie wollen.

Die Verschrottung ist ein relativ einfacher Mechanismus und unterstützt diesen Anwendungsfall nicht.

Die Vorgehensweise bei der Verwendung von Deprecation besteht darin, dass bei einer Verweisung auf eine veraltete Methode oder ein Feld eine Warnung generiert wird.

Die einzige Ausnahme ist, wenn der Code, der die veraltete Methode/das veraltete Feld verwendet, selbst veraltet ist.

Answer 4

Wenn Sie @Deprecated zu Ihrer abgeleiteten Deklaration von Foo() hinzufügen, glaube ich, dass die Warnung verschwindet.

public interface Derived extends Base { 
    @Deprecated void Foo(); 
}