Die Jakarta Persistence API (JPA; früher Java Persistence API) ist eine Schnittstelle für Java-Anwendungen, die die Zuordnung und die Übertragung von Objekten zu Datenbankeinträgen vereinfacht. Sie vereinfacht die Lösung des Problems der objektrelationalen Abbildung, das darin besteht, Laufzeit-Objekte einer Java-Anwendung über eine einzelne Sitzung hinaus zu speichern (Persistenz), wobei relationale Datenbanken eingesetzt werden können, die ursprünglich nicht für objektorientierte Datenstrukturen vorgesehen sind.

Die Jakarta Persistence API wurde als Projekt der JSR 220 Expert Group entwickelt und im Mai 2006 erstmals veröffentlicht. Die Spezifikation der aktuellen Version 3.0 wurde am 26. Oktober 2020 freigegeben.

EclipseLink ist die Referenzimplementierung seit der Version 2.0. TopLink Essentials war die Referenzimplementierung für JPA 1.0.

Konzeption

Neben der API, welche im Package javax.persistence definiert ist, besteht die Jakarta Persistence aus folgenden Komponenten:

Persistence Entity

Eine Persistence Entity ist ein Plain Old Java Object (POJO), das üblicherweise auf eine einzelne Tabelle in der relationalen Datenbank abgebildet wird. Instanzen dieser Klasse entsprechen hierbei den Zeilen der Tabelle. Persistence Entities können je nach Designvorgabe als einfache Datenhaltungs-Klassen (vergleichbar mit einem Struct in C) realisiert werden oder als Business-Objekte inklusive Business-Logik.

Objektrelationale Metadaten

Die Beziehungen zwischen den einzelnen Tabellen werden über objektrelationale Metadaten ausgedrückt. Diese sind entweder als Java-Annotationen angelegt und/oder in einer separaten XML-Datei abgelegt.

Die Jakarta Persistence Query Language

Die Jakarta Persistence Query Language (JPQL) wird genutzt, um Abfragen bezüglich der in der Datenbank gespeicherten Entitäten durchzuführen. Diese Abfragen ähneln syntaktisch SQL-Abfragen, beziehen sich aber auf Entitäten statt auf Datenbanktabellen.

Die JPA-Implementierungen überführen die in JPQL formulierten Abfragen zur Laufzeit in ein SQL-Statement, das vom Zieldatenbanksystem verstanden wird. Durch diese Abstraktion kann das Datenbanksystem transparent ausgetauscht werden, während die Java-Klassen vollständig erhalten bleiben. Im Unterschied dazu erlaubt die JPA auch die Verwendung von "normalen" SQL-Abfragen, wobei diese als Native Query bezeichnet werden. Beim Einsatz von Native Queries muss jedoch der Anwender selbst darauf achten, dass die Abfrage vom Zielsystem verstanden wird.

Jakarta Persistence im Kontext

Viele Javaentwickler benutzten bereits vor dem Aufkommen der Java Persistence API Open-Source Persistenzframeworks. Dies geschah meist mit der Begründung, dass die manuelle Implementierung der Persistenz auf Grund des Object-relational impedance mismatches zu aufwendig und fehleranfällig sei. Die dafür in der Java Platform, Enterprise Edition bis 1.4 vorgesehenen Entity Beans seien durch ihren hohen Ressourcenverbrauch, ihre Komplexität, sowie die Notwendigkeit, auf einem Java-EE-Anwendungsserver zu laufen, aber zu aufwendig. Die Möglichkeiten der vor der Jakarta Persistence API von SUN propagierten Java Data Objects reichten hingegen den wenigsten Entwicklern.

Bei der Entwicklung der Java Persistence API flossen viele Eigenschaften der bereits etablierten Open-Source Persistenzframeworks wie Hibernate und Toplink ein. Diese Frameworks bieten nun teilweise auch Implementierungen der Jakarta Persistence API an.

Jakarta Persistence wurde als Teil der Spezifikation Enterprise JavaBeans 3.0 definiert und stellt somit einen Nachfolger der Entity Beans dar. Obwohl die EJB-3.0-Spezifikation ein Teil der Java-EE-5-Plattform ist, wird für die Verwendung kein EJB-Container oder ein entsprechender Java-EE-Anwendungsserver benötigt. Künftige Versionen sollen daher als separater Java Community Process außerhalb der EJB-Spezifikation definiert werden.

Die Jakarta Persistence API wurde für die relationale Persistenz relativ einfacher Objekte entwickelt. Für Objektdatenbanken muss weiterhin auf Java Data Objects oder ähnliche Frameworks ausgewichen werden. Die Service Data Object (SDO) API hingegen dient hauptsächlich der Abbildung komplexer Daten auf verschiedene Formate und Programmiersprachen für die Verwendung in Serviceorientierten Architekturen.

Allerdings unterstützt die Jakarta Persistence API alle drei Arten der objektrelationalen Abbildung von Vererbungsbeziehungen (Tabelle pro Vererbungshierarchie, Tabelle pro Unterklasse und Tabelle pro konkrete Klasse).

Implementierungen

Die JPA-2.2-Spezifikation wird von einer Reihe an Persistenzframeworks unterstützt, unter anderem von Apache OpenJPA, Hibernate und EclipseLink.

Namensgebung

Die Umbenennung ist auf die Übertragung des Projektes von Oracle an die Eclipse Foundation in 2018 zurückzuführen. Dieser Schritt wird durch die Eclipse Foundation primär mit der Vermeidung rechtlicher Komplikationen begründet. Öffentliche Vorschläge für Namenskandidaten wurden über den Dienst GitHub öffentlich entgegengenommen, wobei die ultimative Entscheidung dem Direktor der Eclipse Management Organisation Mike Milinkovich oblag. Die erste Erwähnung des Terminus Jakarta im Kontext der Umbenennung ist auf den Nutzer Kenneth J. Jaeger zurückzuführen. Zu dem Zeitpunkt des Vorschlages durch Jaeger war die Marke Jakarta Eigentum der Apache Software Foundation, welche jedoch einwilligte, die Rechte an die Eclipse Foundation zu übertragen.

Literatur

  • Bernd Müller, Harald Wehr: Java Persistence API 2. Hibernate, EclipseLink, OpenJPA und Erweiterungen. Carl Hanser Verlag, 2012, ISBN 978-3-446-42693-1.
Wikibooks: Java Persistence – Lern- und Lehrmaterialien (englisch)

Einzelnachweise

  1. ↑ https://github.com/eclipse-ee4j/jpa-api/releases/tag/3.0-3.0.0-RELEASE
  2. ↑ Eclipse Announces EclipseLink Project to Deliver JPA 2.0 Reference Implementation. Eclipse Foundation, 17. März 2008, abgerufen am 27. Juli 2008.
  3. ↑ Gavin King, Christian Bauer, Emmanuel Bernard, Steve Ebersole: Hibernate Getting Started Guide. Abgerufen am 10. Februar 2013 (englisch): „Working with both Object-Oriented software and Relational Databases can be cumbersome and time consuming. Development costs are significantly higher due to a paradigm mismatch between how data is represented in objects versus relational databases.“
  4. ↑ Java Feature — Inheritance Hierarchies in JPA
  5. ↑ David Delabassee: The road to Jakarta EE. In: David Delabassée – DevRel Java Platform Group @ Oracle
    Accessibility Activist.     23. April 2018, abgerufen am 4. September 2023 (englisch).
  6. ↑ David Blevins: Java EE to Jakarta EE. In: Tomitribe. 8. Februar 2018, abgerufen am 14. Januar 2022 (amerikanisches Englisch).
  7. ↑ Wayne Beaton: Brand Name Selection. In: GitHub. 15. September 2017, abgerufen am 14. Januar 2022 (englisch).
  8. ↑ Kenneth J. Jaeger: How about Jakarta Enterprise Edition? In: GitHub. 15. September 2017, abgerufen am 14. Januar 2022 (englisch).
  9. ↑ B. Liyanage Asanka: Java EE renamed to Jakarta EE. In: Medium. 16. März 2018, abgerufen am 14. Januar 2022 (englisch).
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.