--- title: 'Änderungen an Schnittstellen: Code-Kompatibilität und Binär-Kompatibilität' url: 'https://www.tutego.de/blog/javainsel/2012/07/nderungen-an-schnittstellen-code-kompatibilitt-und-binr-kompatibilitt' markdown: 'https://www.tutego.de/blog/javainsel/2012/07/nderungen-an-schnittstellen-code-kompatibilitt-und-binr-kompatibilitt.md' date: '2012-07-02' description: 'Sind Schnittstellen einmal deklariert und in einer großen Anwendung verbreitet, so sind Änderungen nur schwer möglich, da sie schnell die Kompatibilität brechen. Wird der Name einer Parametervariablen umbenannt, ist das kein Problem, aber bekommt eine Schnittstelle eine neue Operation, führt das zu…' taxonomy: category: - Insel --- # Änderungen an Schnittstellen: Code-Kompatibilität und Binär-Kompatibilität ![Illustration einer tropischen Insel mit Palmen und einem hohen Berg](https://www.tutego.de/blog/javainsel/user/themes/tutego/images/insel-cover.jpg)# Java Blog für Programmierer [Java Blog für Programmierer](https://www.tutego.de/blog/javainsel/) ## Änderungen an Schnittstellen: Code-Kompatibilität und Binär-Kompatibilität 02.07.2012 · [Christian Ullenboom](https://www.tutego.de/blog/javainsel/author/admin/) Sind Schnittstellen einmal deklariert und in einer großen Anwendung verbreitet, so sind Änderungen nur schwer möglich, da sie schnell die Kompatibilität brechen. Wird der Name einer Parametervariablen umbenannt, ist das kein Problem, aber bekommt eine Schnittstelle eine neue Operation, führt das zu einem Übersetzungsfehler, wenn nicht automatisch alle implementierenden Klassen diese neue Methode implementieren. Framework-Entwickler müssen also sehr drauf achten, wie sie Schnittstellen modifizieren, doch sie haben es in der Hand, wie weit die Kompatibilität gebrochen wird. Geschichtsstunde Schnittstellen später zu ändern, wenn schon viele Klassen die Schnittstelle implementieren, ist eine schlechte Idee. Denn erneuert sich die Schnittstelle, etwa wenn nur eine Operation hinzukommt oder sich ein Parametertyp ändert, dann sind plötzlich alle implementierenden Klassen kaputt. Sun selbst hat dies bei der Schnittstelle `java.sql.Connection` riskiert. Beim Übergang von Java 5 auf Java 6 wurde die Schnittstelle erweitert, und keine Treiberimplementierungen konnten mehr compiliert werden. **Code-Kompatibilität und Binär-Kompatibilität** Es gibt Änderungen, die führen zwar zu Compilerfehlern, wie neu eingeführten Operationen, sind aber zur Laufzeit in Ordnung. Bekommt eine Schnittstelle eine neue Methode, so ist das für die JVM überhaupt kein Problem. Die Laufzeitumgebung arbeitet auf den Klassendateien selbst und sie interessiert es nicht, ob eine Klasse brav alle Methoden der Schnittstelle implementiert; sie löst nur Methodenverweise auf. Wenn eine Schnittstelle plötzlich „mehr“ vorschreibt, hat sie damit kein Problem. Während also fast alle Änderungen an Schnittstellten zum Bruch der Codebasis führen, sind doch einige Änderungen für die JVM in Ordnung. Wir nennen das Binär-Kompatibilität. Zu den binär-kompatiblen Änderungen zählen: 7. Neue Methode hinzufügen 8. Schnittstelle erbt von einer zusätzlichen Schnittstelle 9. Hinzufügen/Löschen einer throws-Ausnahme 10. Letzten Parametertyp von T\[\] in T… ändern 11. Neue Konstanten, also statische Variablen hinzufügen Die Anzahl der binär-inkompatiblen Änderungen sind jedoch gradierender. Verboten sind: 12. Ändern des Methodennamens 13. Ändern der Parametertypen und Umsortieren der Parameter 14. Formalen Parameter hinzunehmen oder entfernen **Strategien zum Ändern von Schnittstellen** Falls die Schnittstelle nicht groß veröffentlicht wurde, so lassen sich einfacher Änderungen vornehmen. Ist der Name einer Operation zum Beispiel schlecht gewählt, wird ein Refactoring in der IDE den Namen in der Schnittstelle genauso ändern wie auch alle Bezeichner in den implementierenden Klassen. Problematischer ist es, wenn externe Nutzer sich auf die Schnittstelle verlassen. Eine Lösung ist, diese Klienten ebenfalls zur Änderung zu zwingen, oder auf „Schönheitsänderungen“, wie dem Ändern des Methodenamens, einfach zu zu verzichten. Kommen Operationen hinzu, hat sich eine Konvention etabliert, die im Java-Universum oft anzutreffen ist: Soll eine Schnittstelle um Operationen erweitert werden, so gibt es eine neue Schnittstelle, die die alte erweitert, und auf „2“ endet; `java.awt.LayoutManager2` ist so ein Beispiel aus dem Bereich der grafischen Oberflächen, Attributes2, EntityResolver2, Locator2 für XML-Verarbeitung sind weitere. Ein Blick auf die API vom Eclipse-Framework () zeigt, dass bei mehr als 3500 Typen dieses Muster um die 70 Mal angewendet wurde. Seit Java 8 gibt es eine weitere Möglichkeit Operationen in Schnittstellen hinzuzufügen, sogenannte Virtuelle Erweiterungsmethoden. Sie erweitern die Schnittstelle, fügen aber gleich schon eine vorgefertigte Implementierung mit, sodass Unterklassen nicht zwingend eine Implementierung anbieten müssen. Kategorien: [Insel](https://www.tutego.de/blog/javainsel/category/insel/) [← Alle Beiträge](https://www.tutego.de/blog/javainsel/) --- ## Navigation - Previous: [Ressourcen aus dem Klassenpfad und aus Jar‑Archiven laden](https://www.tutego.de/blog/javainsel/2012/07/ressourcen-aus-dem-klassenpfad-und-aus-jar%e2%80%91archiven-laden.md) - Next: [Java 8 bekommt auch eine Optional-Klasse (wie Guava und Scala)](https://www.tutego.de/blog/javainsel/2012/07/java-8-bekommt-auch-eine-optional-klasse-wie-guava-und-scala.md)