Kontroverse um RedHats Data-Grid-JSR für JavaEE 7

Hartmut Schlosser

Die von Red Hat vorgeschlagenen Spezifikationen für die siebte Auflage der Java Enterprise Edition hat kontroverse Diskussionen innerhalb des JCP ausgelöst. Neben den Entwürfen für „Context and Dependency Injection 1.1“ und „Bean Validation“ (ein Verfahren für schichtenübergreifende Konsistenzüberprüfung) hat der Open-Source-Anbieter ein JSR für die Implementierung von Data Grids vorgelegt. Verteilte Datengrids sollen eine einfachere und kostengünstigere Skalierung der Datenschicht ermöglichen und damit umfangreiche Cloud-, Utility- oder mandantenfähige Applikationsplattformen unterstützen.

Der Stein des Anstoßes

Ein konstruktiver Beitrag zur Förderung von Java EE 7 sollte man meinen – was ist also der Stein des Anstoßes? Red Hat wird vorgeworfen, mit dem neuen Data Grid JSR im Grunde die eigene Infinispan Data-Grid-Technologie als Basis für einen Java-Standard vorzuschlagen und damit konkurrierende Ansätze, wie verteiltes Caching in Enterprise Java umgesetzt werden soll, aus dem Rennen zu werfen. Eine Spezifizierung der RedHat-Lösung könnte etwa alternative Lösungen wie Oracles Coherence, VMwares GemStone und Terracottas Ehcache obsolet machen.

In einem Bericht auf PC World äußert sich u.a. Terracotta CEO Amit Pandey kritisch zu dem RedHat-Vorstoß:

While trying to appear beneficial to the community, Red Hat is actually pulling a very self-beneficial move–get their product out in front of the community“ Amit Pandey

Eigentlich war man sich in Expertenkreisen einig darüber, dass eine Spezifizierung des Data Cache in Java EE 7 umgesetzt werden soll. Doch hatten Entwickler von Terracotta, Oracle und auch RedHat im Rahmen des seit 2001 existierenden JSR 107: JCACHE – Java Temporary Caching API an einer Lösung gearbeitet, deren Ergebnisse teilweise auch bereits in Oracles und Terracottas Produkte eingeflossen sind.

So much work has already gone into JS-107. It seems unusual for someone to come in with a completely untested and unadopted product and try to make that the standard Amit Pandey

Den Vorwurf der Eigennützigkeit weist der Red-Hat-Verantwortliche Manik Surtani in einer Antwort auf den PC-World-Artikel zurück. Die Infinispan-Lösung erhalte durch eine Standardisierung möglicherweise eine etwas größere Sichtbarkeit – im Grunde ermögliche die Standardisierung aber, dass Endverbraucher sich von Infinispan leichter lösen und andere Implementierungen nutzen könnten.

Proposing a standard makes it easier for end-users to move away from Infinispan. Yes, it may help with awareness of Infinispan, but it also means Red Hat, just like other data grid vendors, will need to work really hard to make sure their products are up to scratch. The only real beneficiary here is the end-user. In fact, I’d like to invite Terracotta to participate in this JSR, as participation can only make it stronger, more relevant and eventually even more useful to end-users. Manik Surtani

RedHat verteitigt die Positionierung des eigenen Data Grid JSR auch damit, dass JSR 107 nicht mehr zeitgemäß sei und in Hinblick auf eine JavaEE7 Integration ein neuer Anlauf nötig sei:

[JSR 107 has] been inactive for way too long, it is out of date, and the community is pretty jaded about it.“ Manik Surtani

What we’re proposing here is similar, but it will be a standard, and integrated with Java EE. Craig Muzilla, Vice president and General Manager of Red Hat’s middleware business

JSR-107 falls short as a standard for data grids, specifically as it doesn’t take into account characteristics of distribution and replication of data, and doesn’t define a contract that implementations would have to adhere to when it comes to moving data around a cluster. Manik Surtani

Der JCP auf dem Prüfstand

Die Diskussionen um die Data-Grid-Standardisierung könnte sich als Bewährungsprobe für die Funktionsfähigkeit des Java Community Process erweisen. Bekanntlich hat sich Oracle die Wiederbelebung des JCP auf die Fahnen geschrieben, wobei es von entscheidender Bedeutung sein wird, mit neuen Standards die gesamte Java-Community zufrieden zu stellen. Unternehmenspolitische Querelen sind diesem Anliegen sicherlich nicht förderlich, und es bleibt zu hoffen, dass der Java Community ein weiteres Blockadespiel innerhalb des JCP erspart bleibt.

Geschrieben von
Hartmut Schlosser
Kommentare

Schreibe einen Kommentar

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