Federlesen #20: Stabile APIs für eine nachhaltige Entwicklung
Um einen Parallelbetrieb von neuer und alter API zu erreichen und Konflikte möglichst zu vermeiden, sollte man sich einheitliche Versionierungsverfahren für API-Änderungen überlegen.
- Frank Pientka
In der Softwareentwicklung passiert es immer wieder, dass mehrere Versionen einer Bibliothek im Projekt zum Einsatz kommen. Das kann zu Kommunikations- und Kompatibilitätsproblemen führen. Um einen Parallelbetrieb von neuer und alter API zu erreichen und Konflikte möglichst zu vermeiden, sollte man sich einheitliche Versionierungsverfahren für API-Änderungen überlegen.
Apache-Projekte verwenden bei der Versionierung unterschiedliche Strategien. So nutzen die Projekte Isis und Wicket ab Version 6 das Konzept der semantischen Versionierung für ihre Produkte. Dieses läuft meist mit dem Schema <Hauptversionsnummer>.<Nebenversionsnummer>.<Revisionsnummer>. Änderungen in der Revisionsnummer sind Fehlerkorrekturen. Die Nebenversionsnummer kennzeichnet Änderungen im Funktionsumfang, die jedoch abwärtskompatibel sind. Nur Änderungen in der Hauptversionsnummer sind nicht mehr abwärtskompatibel.
Die HttpComponents-Portierung für Android versieht ab Version 4.3 hinzugekommene Klassen
mit dem Postfix HC4, also org.apache.http.**.*HC4, um Konflikte mit älteren HttpComponents-Client-Klassen in der Android-Laufzeitumgebung zu vermeiden. Eine Versionsnummer als Postfix verwendet auch das Apache-Derby-Projekt, indem es bei den Klassen für eine JDBC-4.x-Unterstützung (Java Database Connectivity) die "40" an den Klassenname anhängt, um sie von Klassen zu unterscheiden, die ältere JDBC-Versionen bedienen.
Für die JDBC-4.2-Unterstützung mit Java 8 wurden jedoch die Klassen XYZDataSource40 als "deprecated" markiert und stattdessen die Verwendung der Klassen BasicXYZDataSource40
empfohlen. Eine andere Versionierungsstrategie fahren die Commons-Produkte Lang und Math. Sie machen neuere API-Änderungen im Paketnamen mit einer angehängten Versionsnummer kenntlich, also lang3 beziehungsweise math3.
Beispiel Android-Projekte
Eine häufig verwendete Apache-Bibliothek ist die ehemals Commons HttpClient, jetzt HttpComponents Client genannte Bibliothek. Sie wird in vielen Produkten, unter anderem in der Android Dalvik VM, eingesetzt. Die Dalvik API basiert bei ihren java-Paketen auf dem inzwischen eingestellten Apache-Harmony-Projekt und bei den org.apache.http-Paketen auf der Beta-Version von Apache HttpClient 4.0. Da diese jedoch nur Java 6 unterstützen, hat es bis zur Android-API-Version 20 gedauert, bis Android kompatibel zu den Java-7-Sprachänderungen wurde.
Da sich jedoch Apache HttpClient inzwischen zur Version 4.4 weiterentwickelt hat, ist die von Google
angebotene Version mittlerweile veraltet. Damit zumindest die Abwärtskompatibilität zur Version 4.0 hergestellt ist, bietet Apache das eigene Projekt HttpClient for Android an. Um nicht die von Android bereitgestellten Funktionen zu verwenden, benutzt diese Portierung Android Logging statt Commons Logging, Android Base64 statt der Java-Base64-Implementierung und die Android
SSLCertificateSocketFactory. Entwickler können deshalb das Original durch die portierte Apache-Version ersetzen. Um herauszufinden, welche Version gerade verwendet wird, müssen sie die Klasse org.apache.http.util.VersionInfo aufrufen.
Das bedeutet jedoch auch, dass HttpClient for Android einige Neuerungen wie die nur in der Oracle JVM 1.7 zu findende SNI-Erweiterung (Server Name Indication) des TLS-Standards (Transport Layer Security) oder Java HttpURLConnection in Android nicht unterstützt. Wenn möglich sollten die mit API Level 20 vorhandene Unterstützung für TLS 1.2 und die kritischen Fehlerkorrekturen für den HttpClient verwendet werden.
Eine andere Alternative ist der HttpClient 4.3.2 for Android. Wer SSL/TLS mit SNI unter Android bereits ab Android 2.3 (Gingerbread) und dem API Level 17 verwenden möchte, findet für die SSLCertificateSocketFactory eine in einem entsprechenden Blog-Beitrag beschriebe Lösung.
Fazit
Abschied
Nach 20 Kolumnen in fünf Jahren wurde das Thema Apache Software Foundation samt ihrer Projekte weitreichend behandelt, deswegen gilt es nun, sich von der Federlesen-Kolumne zu verabschieden. Der Autor und die Redaktion bedanken sich bei den Federlesern.
Es gibt unterschiedliche Wege, mit API-Änderungen umzugehen. Neben der Möglichkeit der semantischen Versionierung für ganze Produkte gibt es abgestufte Varianten, die je nach Projekt bei Apache zum Einsatz kommen Das Javadoc-Tag @since sollte auf jeden Fall gesetzt sein, um zu beschreiben, ab welcher Version ein Class, Interface, Enum, Field oder eine Method eingeführt
wurde.
Um den Parallelbetrieb von alten und neuen APIs zu gewähren, gibt es die beiden Möglichkeiten, bei größeren Änderungen entweder den kompletten Paketnamen mit einer Versionsnummer zu versehen oder Klassen mit einer Postfixversionsnummer zu versehen. Für das eigene Projekt kann man sich von den unterschiedlichen Herangehensweisen bei Apache-Produkten inspirieren lassen.
Frank Pientka
ist Senior Software Architect bei der Materna GmbH in Dortmund.
(ane)
