Eclipse Magazin: Warum sollte sich ein Entwickler für EclipseLink entscheiden und nicht für ein anderes Persistenzframework, wie etwa Hibernate?
Doug Clarke: Die direkte Erfahrung von Oracle-Entwicklern und das Feedback externer Anwender haben gezeigt, dass EclipseLink aus folgenden Gründen anderen Lösungen vorgezogen wird:
Erstens wegen der Performanz und Skalierbarkeit. EclipseLinks Qualitäten beim Caching von Entitäten und bei der Abfrageoptimierung erlaubt es Entwicklern, auf effiziente Art und Weise diejenigen Daten zu laden, die sie brauchen, und wiederverwendbare Ergebnisse für spätere Abfrageoperationen zu erhalten. Das Transaktionsframework optimiert die Erkennung von Änderungen und stellt sicher, dass nur die minimalen Änderungen gespeichert werden, unter Berücksichtigung der referentiellen Integrität, des Schutzes vor gleichzeitigem Zugriff und der Cache-Koordination für das Deployment in Clustern.
Zweitens bietet EclipseLink multiple Persistenzservices. Die meisten alternativen Lösungen beherrschen nur objektrelationales Mapping. EclipseLink ermöglicht nichtrelationale Persistenz mit XML-Binding (JAXB), Service Data Objects (SDO) und das Mapping nach JCA Resource Adaptern. Diese Flexibilität erlaubt es Entwicklern, eine einzige Persistenzlösung für alle ihre Bedürfnisse zu verwenden.
Der dritte Vorteil von EclipseLink liegt in der offenen und kollaborativen Community. EclipseLink verfügt über eine große und wachsende Gruppe von Committern und Mitwirkenden. Wir arbeiten hart daran, den Bedürfnissen der Community gerecht zu werden und ermutigen alle zur aktiven Mitarbeit. Das hat uns geholfen, eine große Bandbreite von Entwicklertypen innerhalb der Java-Community zu erreichen.
Eclipse Magazin: EclipseLink wurde als Referenzimplementierung für JPA 2.0 ausgewählt. Wie gestaltet sich die Zusammenarbeit mit der JSR Expert Group?
Doug Clarke: Zurzeit arbeiten wir aktiv an der Implementierung der JPA-2.0-Public-Draft-Spezifikation. Zwei unserer EclipseLink Committer sitzen in der JSR-317-Expertengruppe und bringen ihre langjährigen Erfahrungen und ihr Wissen um unsere aktuelle Implementierung der Draft-Spezifikation ein. Wir arbeiten auch eng mit den Entwicklern von Sun zusammen, die das Technology Compatibility Kit (TCK) schreiben, um eine Koordination der Arbeit nach Fertigstellung der Spezifikation zu erreichen. EclipseLink ermöglicht es den Usern, die neuen Features der Spezifikation sehr früh auszuprobieren. Das Release von EclipseLink 1.1 wird das erste sein, das eine Vorschau auf die JPA 2.0-Funktionalität bietet. Das nächste Major Release von EclipseLink hat zum Ziel, die gesamte Funktionalität bereitzustellen. Interessierte Entwickler können über die Milestone-Builds früh auf die bereits umgesetzten Funktionen zugreifen und Kommentare an die Expertengruppe und die EclipseLink Committer abgeben.
Eclipse Magazin: Als Referenzimplementierung für JPA 2.0 setzt EclipseLink vor allem diese Spezifikationen um. Andererseits beobachten wir auch immer Rückwirkungen der Implementierung auf die Spezifikation. Welche Wechselwirkungen gibt es zwischen EclipseLink und JPA 2.0? Welche Funktionen von EclipseLink werden wir zum Beispiel in JPA 2.0 wiederfinden?
Doug Clarke: Es gibt bereits einige Schlüsselfunktionen von JPA 2.0, die über die Unterstützung von JPA 1.0 hinaus den EclipseLink-Usern bereits zur Verfügung stehen:
- Pessimistic Locking
- Flexible Zugriffsarten
- Element Collection – Sammlungen von einfachen Datentypen
- Ein API für die programmatische Definition von Abfragen
- Cache-Zugriffe, Cache-Bereinigung und Verwendungshinweise
- Verschachteln von und Beziehungen zwischen Embeddables
- "Derived IDs": Fremdschlüssel-Mappings können Teil des Primärschlüssels einer Entität sein
- "Private owned": Unterstützung für Parent-Child-Beziehungen
- Verschachtelte Fetch Joins
- Collection-Parameter für IN-Ausdrücke
Wir werden auch weiterhin innovative Funktionen für diejenigen integrieren, die mehr als die üblichen Funktionalitäten benötigen, und uns bemühen, diese kompatibel zum Standard zu halten.
Eclipse Magazin: Die EclipseLink zugrunde liegende Codebasis ist seit vielen Jahren im produktiven Einsatz erprobt. Worin besteht die aktuelle Weiterentwicklung von EclipseLink, abgesehen von der Umsetzung von JPA 2.0? Was können wir in 2009 erwarten?
Doug Clarke: Wir haben ein sehr arbeitsintensives Jahr vor uns, in dem uns sowohl die Umsetzung von JPA 2.0 als auch die Integration vieler neuer Funktionen, die von der Community an uns herangetragen wurden, beschäftigen wird.
Bei dem Java Persistence API (JPA) wollen wir den erweiterten XML-Support auf alle EclipseLink-Features ausdehnen. Außerdem werden wir uns mit Migrationswerkzeugen beschäftigen, die den Umstieg von anderen Persistenzlösungen auf EclipseLink erleichtern sollen.
Wir streben die Kompatibilität zu SDO 2.1.1 an und wollen einen Data Access Service für SDO via JPA bauen. Bezüglich MOXy ist geplant, die Nutzung von Mappings mit nativen Annotations zu verbessern und die Kombination von Annotation- und XML-Konfigurationen zu ermöglichen.
Wir werden uns auch mit Benchmarking-Fragen beschäftigen, um die überlegene Performanz von EclipseLink unter Beweis zu stellen. Es fehlt außerdem noch an Beispielen und einer überarbeiteten Dokumentation. Und wir werden weiterhin mit dem Eclipse-Ökosystem zusammenarbeiten: Einbezug in das Eclipse Galileo Release, verbesserte Nutzung von OSGi/Equinox, Support von EclipseLink-Werkzeugen im Eclipse-Dali-Projekt, Zusammenarbeit mit anderen Eclipse-Projekten wie Teneo und Swordfish bei ihrer Einbindung von EclipseLink in ihre Produkte.
Eclipse Magazin: Doug, wir danken dir für dieses Gespräch.
Die Fragen stellten Stefan Scheidt und Sebastian Meyen.
