Interview mit Oliver Gierke

"Damit JSR-Implementierer nicht mehr im Trüben fischen" – kontroverse Diskussion über TCK-Zugang für Expert Groups

In der JPA 2.1 Expert Group wird derzeit eine interessante Diskussion über die Zugänglichkeit der Technology Compatibility Kits (TCK) für JSRs geführt. Diese TCKs werden dazu verwendet, um Implementierungen von JSR-Spezifikationen auf ihre Korrektheit zu überprüfen. Oliver Gierke (VMware) kritisiert nun die aktuelle Praxis, dass TCKs nicht von den jeweilgen Expert Groups der JSRs definiert werden und Implementierer bis zur Fertigstellung einer Spezifikation eigentlich keine Möglichkeit haben, ihre Implementierungen zu testen. Wir sprachen mit Oliver über die aktuelle Situation und über Verbesserungsmöglichkeiten hin zu einem transparenten, offenen TCK-Prozess.

JAXenter: Hallo Oliver. Ihr führt in der JPA 2.1 Experten-Gruppe eine Diskussion um die Verfügbarkeit der TCKs. Welche Rolle spielen diese TCKs eigentlich?

Oliver Gierke: Bevor ich der JPA Expert Group beigetreten bin war davon ausgegangen, dass die TCKs von den Expert Groups mitdefiniert werden, um so sicherzustellen, dass das, was in der Spezifikation definiert wurde, auch von den Implementierern umgesetzt wird.

Durch meine Arbeit an Spring Data JPA bin ich jedoch wiederholt auf Fehler in den Persistenzprovidern gestoßen, die darauf hinwiesen, dass scheinbar essentielle Methoden der API entweder gar nicht von Testfällen abgedeckt waren bzw. diese ungenügend strikt sind [1].

Ich habe daraufhin nachgefragt, wie man denn potentiell das TCK verbessern könnte, bekam aber keine Antwort.

Also habe ich mein Bemühen intensiviert, Teil der Expert Group zu werden, bis ich zu meinem Erstaunen feststellen musste, dass auch diese eben keinen direkten Zugriff auf das TCK hat. Alles, was wir tun können, ist eine Email zu schreiben, die auf potentielle Probleme hinweist, und dann hoffen, dass diese irgendwie adressiert werden.

JAXenter: TCKs werden also allein von Oracle kontrolliert und weiterentwickelt?

Oliver Gierke: Genau so ist es. Die Expert Group hat bis zum finalen Release des JSR keinen Zugriff auf das TCK. Diesen bekommen auch nach dem Release auch nur Lizenznehmer. Zu diesem Zeitpunkt ist der JSR jedoch bereits komplett verabschiedet, und Probleme im TCK sind schwer zu identifizieren. Es gibt nur einen sehr vagen Rückkanal für Feedback: eine Email an den Speclead.

JAXenter: Kannst du vielleicht anhand eines kleinen Beispiels erklären, was an der aktuellen Situation problematisch ist?

Oliver Gierke: Nun ja, stellen wir uns einmal folgendes Szenario vor: Wir haben ein Team von ca. 10 Parteien, die Anforderungen an eine Software spezifizieren. Das Team tut das jedoch, ohne Testfälle zu definieren. Weiterhin starten Entwicklungsteams, auf Basis dieser Spezifikation Implementierungen zu entwickeln. Man kann Rückfragen zur Spezifikation stellen, jedoch keine zur Testsuite, die man später erfüllen muss. Konkret heißt das, man entwickelt faktisch ins Blaue. Parallel dazu entwickelt jemand völlig isoliert Testfälle zu eben dieser Spezifikation. Es gibt keine Rückfragen, kein Feedback, nichts.

Nun wird diese Spezifikation verabschiedet, d.h. sie ist ab diesem Zeitpunkt in Stein gemeißelt. Exakt zu diesem Zeitpunkt bekommen die Implementierer den Satz an Testfällen überreicht, und deren Hauptaufgabe ist nun eigentlich, ihre bisherige Implementierung gegen das TCK zum Laufen zu bekommen. Inwieweit das TCK jetzt überhaupt die Anforderungen der Spezifikation abdeckt, oder Teile der Spezifikation ungetestet sind, ist zu keinem Zeitpunkt irgendwie überprüfbar.

Würden wir so heutzutage Softwareprojekte abwickeln? Ich bin mir sicher, dass es solche Projekte in der realen Welt gibt. Allerdings ist das nicht unbedingt die Art und Weise, in der gute Softwareprojekte gebaut werden. Und schon gar nicht, wenn es sich bei dem Projekt um einen Java Standard handelt, den Entwickler für Jahre – wenn nicht sogar Jahrzehnte – nutzen werden.

Um zurück zu den JSRs zu kommen: Wir haben hier ja jetzt das zusätzliche Problem, dass die Implementierungen zertifiziert werden können. Was genau tun wir denn nun, wenn man im nachhinein feststellt, dass es spezifikationsverletzende Fehler in den Implementierungen gibt, die auf ein Loch im TCK zurückzuführen sind? Die Implementierung dezertifizieren?

Es gibt faktisch keinen „Prozess“ für den Umgang mit Fehlern bzw. fehlenden Tests im TCK und der Art und Weise, wie Zertifizierungen dann korrigiert werden müssen, usw. Ein Grund mehr, warum es wichtig ist, von Anfang an zu einem soliden TCK zu kommen.

Es besteht also potentiell – und wie ich erfahren musste auch ganz praktisch – eine große Lücke zwischen dem, was spezifiziert ist, und dem, was über das TCK von den Implementierern verlangt wird. Und das ist vor allem ein großes Problem für die Portierbarkeit von Applikationen auf diesem Standard bishin zur Fragestellung, ob es Sinn macht, gegen eine Methode zu programmieren, die zwar vage semantisch definiert wurde aber letztendlich von allen großen Persistenzprovidern unterschiedlich implementiert wird. Hier wird der Wert einer Spezifikation fundamental unterlaufen [2].

Und man kann durchaus die Frage stellen, was für einen Sinn es macht, an einer Spezifikation zu arbeiten, wenn das, was letztendlich für die Implementierer – und somit auch für die Entwickler, die gegen das API programmieren – zählt, irgendwo komplett separat definiert wird und es darüber hinaus keine Mittel gibt zu überprüfen, inwieweit das TCK überhaupt mit der Spezifikation übereinstimmt.

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.