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

JAXenter: Sind das Probleme, die speziell für JPA relevant sind? Oder anders gefragt: Wird in anderen Experten-Gruppen eine ähnliche Diskussion geführt?

Oliver Gierke: Kernpunkt hier ist, dass jeder JSR nach einer bestimmten Version des Java Community Process (JCP) durchgeführt wird, der den Prozess definiert, wann welche Spezifikationsartefakte abzulieferen sind und unter welcher Lizenz diese zu veröffentlichen sind. Einige Spezifikationen (wie z.B. JPA) halten sich da sehr strikt daran. Ich weiß allerdings von anderen Spezifikationen wie z.B. CDI, dass man hier auch offener arbeiten kann. Das TCK von CDI war während der gesamten Spezifikationszeit unter Apache-Lizenz verfügbar. So wird die große Lücke eben vermieden, und man fördert gleichzeitig die Integration der Community. Das heißt natürlich nicht, dass damit alle Mehrdeutigkeiten in der Spezifikation ausgeschlossen sind, die Spezifikationslücke wird jedoch deutlich geringer.

JAXenter: Was schlägst du konkret vor, um die aktuelle Situation zu verbessern?

Oliver Gierke: Mir schweben eigentlich zwei Dinge vor: Erstens sollte das Erarbeiten des TCK mit der Spezifikation einhergehen. Man könnte zum Beispiel darauf bestehen, dass kein API spezifiziert werden kann ohne, dass es klare Testfälle für eben dieses gibt. Das erfordert natürlich, dass zumindest die Expert Group Zugriff auf diese Testcases bekommt. Das würde vor allem den Implementierern helfen, da diese dann nicht zwei Jahre im Trüben implementieren müssten. Der zweite Punkt, den ich begrüßen würde, ist eine Regelung, wie mit TCK-Lücken umgegangen wird. Es muss einen Weg geben, die Testsuite kontinuierlich zu verbessern.

JAXenter: Würdest du es begrüßen, wenn die TCKs völlig quelloffen der Community zur Verfügung gestellt würden?

Oliver Gierke: Ja. Dass das geht, zeigt, wie schon erwähnt, die CDI-Spezifikation. Das TCK gibt es bei GitHub [3]. Für jeden fork- und verbesserbar. Warum sollte das nicht für andere JSRs auch funktionieren?

JAXenter: Linda DeMichiel von Oracle schreibt auf der Mailing-Liste, dass es bei Oracle kein spezielles Team für die JPA TCKs gibt. Dabei deutet sie an, dass TCKs für andere JSRs schon früher fertig geworden sind. Wurden andere Experten-Gruppen also früher bedient? Und dann hört sich das irgendwie so an, als wäre das TCK Team nicht besonders stark besetzt, sodass die Bereitstellung eben viel Zeit in Anspruch nimmt.

Oliver Gierke: Das ist ein sehr guter Punkt. Es ist schwer, Details darüber zu bekommen, wer in welchem Umfang am TCK für JPA 2.1 arbeitet. Linda schrieb auch in einer weiteren Email, dass es bisher kein so großes Interesse daran gab, am TCK mitzuhelfen. Mir ist an der Stelle wichtig klarzustellen, dass es mir nicht darum geht zu sagen: Person X oder Y tut schlechte Arbeit. Mein Punkt ist, dass der aktuelle „Prozess“ meiner Meinung nach Probleme hat und die Qualität des Standards beeinträchtigt.

Dass ein besseres TCK mehr Arbeit bedeutet, ist auch mir klar, und ich bin gerne bereit, dabei zu helfen. Vielleicht lassen sich auch über das Adopt-a-JSR-Programm noch mehr Freiwillige finden, die mithelfen würden. Ich glaube nur, dass es zum einen schwierig ist, Unterstützung zu finden, wenn es faktisch unmöglich ist, zu helfen. Zum anderen glaube ich, dass vielen bisher nicht bewusst war, welch große Lücke hier besteht und warum der aktuelle Zustand überhaupt problematisch ist.

Kommentare

Schreibe einen Kommentar

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