entwickler.de

Das Hibernate-Framework ist spätestens, seit die Konzepte von Hibernates Java Persistence API (API) über die EJB 3-Spezifikation Einzug in die Java Enterprise Edition (Java EE) 5 gefunden haben, zum De-facto-Standard in Sachen Persistenz in der Java-Entwickler-Welt geworden. Java Magazin-Autor Michael Plöd suchte die beiden Chefentwickler, Gavin King und Christian Bauer, auf, um mehr zum Status quo von Hibernate und was in Zukunft zu erwarten ist zu erfahren.

Hibernate unterstützt schon jetzt Hunderte von Object-Relational Mapping Features und ist in der aktuellen Version sehr ausgereift. Welche Features seht ihr in kommenden Hibernate Versionen? Wo wird sich Hibernate in der Zukunft hinbewegen?
Gavin King: Google hat kürzlich seine "Sharding"-Technologie als Open Source freigegeben. Mit Sharding lassen sich große Datensätze über mehrere Server segmentieren. Diese Technologie wird als "Hibernate Shards" veröffentlicht und ermöglicht es, Hibernate viel skalierbarer zu machen.

Christian Bauer: Im letzten Jahr waren wir sehr damit beschäftigt, die Java-Persistence-Spezifikation in den Hibernate Annotations und dem Hibernate EntityManager umzusetzen. Deshalb hatten neue Features nicht die größte Priorität. Das wird sich in diesem Jahr jedoch ändern und wir sind schon dabei, neue Module zu liefern. Zum Beispiel eine Integration von Lucene, Annotations für Datenvalidierungen und die Daten-Partitionierung, die Gavin eben ansprach. Aus einer reinen ORM-Perspektive befindet sich Hibernate momentan in einer Phase der Optimierung und kleiner Refactorings. So arbeiten wir momentan beispielsweise an einem besseren API für Criteria Queries.

Ich gehe davon aus, dass das neue Criteria API HQL-basiert sein wird?
Christian: Diesbezüglich gibt es immer eine interne und eine externe Sicht auf die Dinge. Intern werden wir die Criteria-Query-Implementierung auf einem überarbeiteten HQL Parser aufbauen, sodass die Features der Criteria Queries nicht mehr ein Subset von HQL, sondern genau so mächtig sind. Aus externer Sicht werden wir wahrscheinlich ein paar neue Methoden anbieten, allerdings wird sich nicht sehr viel ändern, weil es meiner Meinung nach an dieser Stelle nicht mehr viel zu verbessern gibt. Des Weiteren ist ein Upgrade so auch einfacher.

Überlegt ihr auch, neue Entity Modes in Zukunft zu unterstützen?
Christian: Momentan unterstützt Hibernate drei Entity Modes. Du kannst Entities als einfache Java-Klassen, verschachtelte Hash Maps oder als XML-Dokumente umsetzen. Das ist momentan nicht erweiterbar und es wäre auch nicht einfach, eine Erweiterung umzusetzen. Eine Erweiterbarkeit der Entity Modes ist auf der Wunschliste für eine zukünftige Hibernate-Version, vielleicht sogar unter den Top 10 der größeren Verbesserungen.

In Hibernate 3.2 wurden zahlreiche Features für die EJB 3-Kompatibilität hinzugefügt. Des Weiteren ist es nun möglich, den Bytecode Enhancer auszutauschen. Warum würde ich als Entwickler CGLIB gegen Javassist tauschen wollen?
Christian: Diese Veränderung war primär dadurch getrieben, dass wir Abhängigkeiten reduzieren wollen. Hibernate ist als EJB 3.0 Persistenz Provider Bestandteil des JBoss Application Server und Javassist wird in diesem als Bytecode Enhancer verwendet. Somit machte es Sinn, diesen Teil von Hibernate austauschbar zu machen, sodass man auf Javassist wechseln kann, wenn Hibernate als Bestandteil von JBoss AS ausgeliefert wird.

Ist es somit aus Sicht des Hibernate-Teams zu empfehlen, wenn man im JBoss AS Javassist auch als Hibernate Bytecode Enhancer verwendet?
Christian: Ja, weil man so eine Abhängigkeit weniger verwalten muss. Es gibt keinen Unterschied in Bezug auf die Funktionalität und die Performance, weil Javassist und CGLIB so verwendet werden, dass sie fast den gleichen Proxy Bytecode erzeugen. Mit JDK 1.4 aufwärts braucht man auch auch nicht mehr die Reflection-Optimierungen dieser Bibliotheken.

In eurem Hibernate-Blog hast du (Christian) die Verwendung von Abstraktions-Frameworks im Zusammenhang mit ORM-Technologien wie Hibernate oder JPA kritisiert. Könntest du deine Kritik bitte kurz erklären?
Christian: Das ist ein schwieriges Thema. Die meisten Frameworks versuchen, Dinge einfacher zu machen, indem oft verwendete Funktionalität in wieder verwendbaren Modulen abstrahiert wird. Man muss also ständig herausfinden, was die Leute verwenden und wie man das verbessern könnte. Das hat sich bei Hibernate im Laufe der Zeit verändert und jede neue Hibernate-Version versucht natürlich, die oft verwendeten Features so einfach zugänglich wie nur irgendwie möglich zu gestalten. Momentan beobachten wir, dass von unseren Benutzern Frameworks und Wrapper für Hibernate verwendet werden, die eigentlich gar nicht mehr nötig sind. Wir versuchen, das zu ändern, allerdings ist das nicht ganz einfach, weil viele neue Entwickler irgendwo veraltete Tutorials lesen und beispielsweise denken, dass es nötig ist, Exceptions zu wrappen, die von Hibernate geworfen werden.

JPA ist jetzt final. Wie stark schätzt ihr die Spezifikation ein? Insbesondere im Hinblick auf das Fehlen einiger Features wie z.B. FlushMode.NEVER?
Christian: Ich bin ganz glücklich mit der Spezifikation. Vor allem finde ich die enge Integration in das neue EJB 3-Programmiermodell sehr gelungen. Dennoch: Ein paar kleine Dinge fehlen noch oder sie könnten detaillierter ausgearbeitet sein. Beispielsweise ein manueller Flush Mode für den Persistenz-Kontext, Pessimistic Locking und Collections mit Value Mappings. Auf der anderen Seite bin ich aber vom Scope der standardisierten Mapping-Funktionalität beeindruckt und ich bin überzeugt, dass das API und die Query-Sprache ein stabiles und gut erprobtes Feature-Set festlegen.

Gavin: Eines der Hauptziele der nächsten Überarbeitung von JPA wird die Aufnahme eines Criteria API sein. Ich bin sehr hoffnungsvoll, dass sich die Expert Group dieses mal auf die Unterstützung eines atomaren Persistenz-Kontexts mit manuellem Flush Modus einigen kann. Es wäre natürlich sehr hilfreich, wenn die Entwickler den Druck auf die Expert Group diesbezüglich aufrechterhalten würden. Ich würde auch gerne die Einführung eines SPI, das eine effizientere Replikation von Persistenz-Kontexten in geclusterten Umgebungen ermöglicht, sehen. Ich kann mir auch vorstellen, dass es neue Features in der Query-Sprache geben wird - ich hab da schon eine Wunschliste.

Welche Features von JBoss Seam werden im Rahmen des Web Beans JSR standardisiert werden?
Gavin: Eine wahrscheinlich unvollständige Liste der Punkte, an denen ich arbeiten möchte, enthält das Unified Component Model, das Context Model, "Bijection" und das Verdrahten von kontextbasierten Komponenten, das Conversation-Konzept und die an Conversations gebundenen EJB 3-Persistenz-Kontexte. Das sind eigentlich die Kern-Features, die Seam so einzigartig machen.

Wie wichtig ist aus eurer Sicht der Support verschiedener Plattformen wie WebSphere oder WebLogic für den Erfolg von JBoss Seam?
Gavin: Die Seam-Community ist im Laufe der letzten drei Monate explodiert und wir sehen, dass viele Leute jetzt Seam-basierte Anwendungen auf allen möglichen Plattformen entwickeln. Vor ein paar Monaten waren die meisten Seam User noch auf dem JBoss AS, aber das ändert sich gerade sehr schnell.

Christian: Seam basiert auf Java SE 5.0 und Annotations und viele Teams können jetzt mit JDK 5.0 entwickeln, weil IBM, BEA etc. ihr OK gegeben haben. Das ist eigentlich ein natürlicher Migrationspfad in die Welt von JSF, Seam und Hibernate und später natürlich in Richtung Java EE 5.0/EJB 3.0 (sobald das von den entsprechenden Herstellern unterstützt wird).

In den letzen Monaten habt ihr verschiedenen 1.1.x-Versionen von Seam eine Menge neuer Features hinzugefügt. Welche sind die wichtigsten und was ist für die nächsten Versionen geplant?
Gavin: Ein paar stechen hier hervor: Security ist eine universelle Anforderung an jede Anwendung und wird (in den meisten Frameworks) entweder vernachlässigt oder bis ins Absurde über-designed. Unsere User haben danach gebettelt. Seam-gen ist auch sehr wichtig, es ermöglicht den Entwicklern, schnell und problemlos mit Seam produktiv arbeiten zu können, ohne sich tagelang mit Build-Skripten und Paketierung beschäftigen zu müssen. Gleichermaßen entfernt die Integration von Spring eine weitere Hürde, was die Adaption von Seam angeht. So können die Entwickler bestehenden Code wieder verwenden und ihre Spring/Hibernate-Anwendungen Stück für Stück in Richtung Seam umstellen. Die großen Punkte auf der Roadmap sind aktuell die Integration von Web Services und JBoss ESB, jBPM Workflows, die durch E-Mail oder JMS angestoßen werden, und, natürlich, die Integration von RichFaces und das Eclipse Tooling, das wir von Exadel übernommen haben. Wir haben große Pläne für die Tool-Unterstützung von Seam und werden damit die Produktivität auf ein neues Level heben.

Hibernate wurde zu einem Zeitpunkt von JBoss übernommen, an dem das Projekt gerade am "durchstarten" war. Was hat sich seitdem in der Arbeit des Hibernate-Teams geändert?
Christian: Wir mussten sehr früh lernen, wie man mit einem schnell wachsenden Projekt umgeht, schon bevor wir zu JBoss gegangen sind, als wir noch nicht Vollzeit an dem Projekt arbeiten konnten. So haben wir sehr effiziente Strategien gefunden, wie man mit sich ständig ändernden Zielen und Entwicklern, die in verschiedenen Teilen der Erde wohnen, umgeht. Das wurde natürlich sehr viel einfacher, als wir Vollzeit an dem Projekt arbeiten konnten. Allerdings arbeiten wir immer noch genau so wie vor vier Jahren, sogar mit den gleichen Tools.

Was habt ihr gelernt, wie man am besten mit einem verteilten Team arbeitet?
Gavin: Wenn man täglich mit den gleichen Leuten in einem Büro arbeitet, weiß man sehr schnell, wer für was zuständig und wer in was spezialisiert ist. In einem verteilten Team wird die persönliche Kommunikation durch Kommunikation über das Internet ersetzt und es entsteht natürlich eine gewisse Verzögerung. Des Weiteren muss man mit verschiedenen Zeitzonen umgehen. Also ist es sehr wichtig, dass man die richtigen Kommunikations-Tools findet und dass die Leute ihr Wissen im Team (mit)teilen können.

Vielen Dank für das Interview!

Die Fragen stellte Michael Plöd, Chief Developer bei der Senacor Technologies AG .