Nachdem im ersten Teil der JPA Einführung die Infrastruktur für die Arbeit mit JPA fertig gestellt wurde, kommen wir nun zu den Entitätsklassen. Bei den Entities handelt es sich um ganz normale Java Klassen (POJOs), die kein spezielles Interface implementieren oder von einer vorgegebenen Oberklasse erben müssen. Lediglich ein default Konstruktor muss vorhanden sein.
Dank JPA Annotationen kann man erkennen, dass die Objekte persistiert werden.
Möchte man EJB3 konform arbeiten, so sollten die Annotationen dort angebracht werden, wo auf die Properties zugegriffen wird: An den Attributen für field-access, an den Getter-Methoden bei property-access. Dies sollte konsistent gemacht werden, und die beiden Formen sollten nicht gemischt werden. (Zwischen den beiden Formen wird über die Position der @Id Annotation unterschieden.)
Die Annotation der Attribute hat dabei den Vorteil, dass schnell erkennbar ist, was wie persistiert wird – kann jedoch bei einigen JPA Providern zu Performance Problemen führen. Auf der anderen Seite führen Getter-Methoden, die nicht zu persistierende Werte liefern und nicht explizit von der Persistierung ausgenommen werden zu möglicherweise schwer zu findenden Programmfehlern.

Ein Beispiel für eine einfache Entitätsklasse

@Entity
public class Person {
@Id
@GeneratedValue
private Long id;
private String vorname;
private String nachname;
// default constructor
public Person () {
}
// getter + setter
}

Die @Entity Annotation macht kenntlich, dass diese Klasse von JPA persistiert werden soll, @Id kennzeichnet den Primärschluessel und @GeneratedValue bedeutet, dass dieser automatisch generiert werden soll (also ein synthetischer Primärschlüssel).
Mit diesen wenigen Angaben ist bereits erreicht, dass Objekte der Person Klasse persistiert werden können – lediglich die Konfiguration der Datenbank für JPA fehlt noch. Die genaue Steuerung in welche Tabellen/Spalten die Speicherung in der Datenbank erfolgt ist optional, und wird ohne zusätzliche Konfiguration mit Default-Werten realisiert.

JPA persistence.xml Konfiguration

In der Datei “persistence.xml” (normalerweise im META-INF Verzeichnis) befindet sich die Datenbankkonfiguration fuer den JPA Provider.
Ein verkürztes Beispiel passende zu der Beispiel-Entität von oben:
<persistence xmln="http://java.sun.com/xml/ns/persistence" ... >
<persistence-unit name="addressbook">
<class>com.example.domain.Person</class>
<properties>
<property name="hibernate.connection.driver_class" value="org.hsqldb.jdbcDriver" />
...
</properties>
</persistence-unit>
</persistence>
Zuerst erfolgt die Angabe des symbolischen Namens unter welchem diese Konfiguration verfügbar gemacht wird, dann folgt welche Klasse(n) zu persistieren sind (falls diese nicht per @Entity bereits deklariert sind, je nach JPA Provider reicht die @Entity Annotation nicht aus) und schließlich die Konfiguration der Datenbankverbindung ueber den JPA Provider Hibernate.
Theoretisch sind verschiedene Persistence-Units möglich, ebenso kann über <provider> explizit der JPA Provider konfiguriert werden. In der Praxis findet sich jedoch für eine Anwendung in der Regel eine Persistence Unit und lediglich eine JPA Implementierung, die dann auch standardmäßig verwendet wird.
Die Properties des JPA Providers sind dabei spezifisch für den jeweiligen Provider – in diesem Fall Hibernate.

Objekt mittels JPA speichern

Nun fehlt nur noch, dass ein Entity Object mittels JPA auch gespeichert wird. Nachdem die Vorarbeiten erledigt sind, zeigt sich schnell wie einfach die Arbeit Objekte zu speichern und zu laden dank JPA wird:
EntityManagerFactory emf =
Persistence.createEntityManagerFactory("addressbook" ); //der symbolische Name
EntityManager em = emf .createEntityManager();
EntityTransaction tx = em.getTransaction();
tx.begin ()
Person p = new Person ();
...
em.persist(p);
tx.commit();
em.close();
Im nächsten Teil folgt dann wie Objekte aus der Datenbank geladen, geändert und auch gelöscht werden können.

Weitere Artikel:

1. JPA Tutorial: JPA Einrichtung

JPA, die Java Persistence API bietet im Vergleich zu JDBC ein erhöhtes Abstraktionsniveau und ermöglicht damit in kurzer Zeit Anwendungen zu entwickeln, in denen Daten dauerhaft gespeichert werden müssen.
Zum Hintergrund von JPA: Bei dem Umgang mit Datenbanken gibt es schon sehr lange JDBC (Java Database connectivity) als einheitliche API um die Verbindung zu Datenbanken herzustellen. Auch hier handelt es sich bereits um eine einheitliche Schnittstelle, jedoch wird darüber lediglich festgelegt, wie Verbindungen aufgebaut werden, wie eine Abfrage eingeleitet wird und wie Transaktionen manuell gesteuert werden können.
Damit bleiben zwei Probleme: Der SQL Code muss von Hand erstellt werden, was gerade bei CRUD (Create, Update, Delete) Anwendungen viel Produktivität kostet, und zudem ist der SQL Code in der Regel herstellerabhängig. Ein Wechsel von Oracle zu Postgres bedeutet damit das Programm an vielen Stellen ändern zu müssen. Auch sind händisch erstellte Abfragen nicht immer optimal: Lazy loading von Entitäten, Caching Strategien und Transaktionssteuerung können sehr aufwendig werden. Dazu gesellen sich der relativ hohe Wartungsaufwand und die Gefahr von Fehlern die erst zur Laufzeit entdeckt werden.Das Beispielprojekt wird ein einfaches Adressbuch, dabei werden Personen und ihre zugehörigen Adressen gespeichert. Im ersten Teil beschäftigen wir uns damit die Projektstruktur einzurichten, und die nötigen Bibliotheken zu installieren.

Dependencies

JPA selber ist lediglich eine API – diese wird durch einen sogenannten JPA Provider implementiert. Hibernate, OpenJPA und EclipseLink (bzw. Oracle Toplink) sind Beispiele fuer JPA Provider, die als OpenSource zur Verfuegung stehen und auch kommerziell verwendet werden koennen.
Am einfachsten lassen sich diese Abhaengigkeiten durch Maven erfuellen, Maven kuemmert sich dabei um Download der direkten und indirekten (transistiven) Dependencies. Fuer diejenigen, die bereits Maven Erfahrung haben und Maven mit JPA nutzen moechten, hier ein Beispiel (weiter unten findet sich ein fertiges Eclipse Projekt ohne Maven zum Download) fuer Hibernate als JPA Provider (und SLF4J zum Loggen):
<dependencies>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>3.3.2.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-annotations</artifactId>
<version>3.4.0.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-entitymanager</artifactId>
<version>3.4.0.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-c3p0</artifactId>
<version>3.3.2.GA</version>
</dependency>
<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-ehcache</artifactId>
<version>3.3.2.GA</version>
</dependency>
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-simple</artifactId>
<version>1.5.8</version>
</dependency>
<dependency>
<groupId>org.hsqldb</groupId>
<artifactId>hsqldb</artifactId>
<version>1.8.0.10</version>
</dependency>
</dependencies>

Manuelle Einrichtung

Hier eine Liste der nötigen Bibliotheken, für diejenigen, die von Hand (beinhaltet alle transitiven Abhängigkeiten) das Projekt konfigurieren möchten:

• antlr-2.7.6.jar
• c3p0-0.9.1.jar
• commons-collections-3.1.jar
• commons-logging-1.0.4.jar
• dom4j-1.6.1.jar
• ehcache-1.2.3.jar
• ejb3-persistence-1.0.2.GA.jar
• hibernate-annotations-3.4.0.GA.jar
• hibernate-c3p0-3.3.2.GA.jar
• hibernate-commons-annotations-3.1.0.GA.jar
• hibernate-core-3.3.2.GA.jar
• hibernate-ehcache-3.3.2.GA.jar
• hibernate-entitymanager-3.4.0.GA.jar
• hsqldb-1.8.0.10.jar
• javassist-3.4.GA.jar
• jta-1.1.jar
• slf4j-api-1.5.8.jar
• slf4j-simple-1.5.8.jar
• xml-apis-1.0.b2.jar

Diese JAR Dateien werden in den Classpath gelegt, normalerweise in einen “lib” Ordner, und anschließend wird der Classpath entsprechend konfiguriert. (In Eclipse über Rechtsklick auf das Projekt “Properties” im Menü auswählen, dann “Java Build Path” und dort mittels “Add JARs” die entsprechenden Dateien hinzufügen.)

JPA Projekt Download

Der Download als fertiges Eclipse Projekt (hier: Eclipse JPA Project) beinhaltet die nötigen JAR Dateien im “lib” Ordner, ist bereits entsprechend konfiguriert und benötigt kein Maven oder andere externe Tools.  (Die Ordnerstruktur verwendet jedoch die Maven Verzeichnisstruktur, was jedoch keine große Umstellung bedeuten sollte.)

Für dies Beispiel wird hsql als Datenbank verwendet, und dabei separat gestartet. Je nach Anwendung (Desktop oder Server) würde man in der Regel eine eingebettete Datenbank (Swing/Desktop Anwendung) oder eine externe Datenbank (Java Enterprise Application) verwenden. Hsql bietet den Betrieb als Embedded- und Standalone-Datenkbank an, dabei ist die JAR Datei mit rund 700kb relativ schlank und kann somit sehr gut für dieses Tutorial eingesetzt werden.

Um HSQL zu konfigurieren gibt es die Datei “server.properties”, die eine Datenbank konfiguriert, die in dem Ordner “db” abgelegt wird, “addressbook” heisst und auch als “addressbook” angesprochen wird.
Server properties:
server.database.0=db/addressbook
server.dbname.0=addressbook

Von der Kommandozeile startet man den HSQL Server dann aus dem Projekt Verzeichnis in dem sich der “db” Ordner, der “lib” Ordner mit der hsqldb JAR Datei  und die “server.properties” Datei befindet:
java -cp lib/hsqldb-1.8.0.10.jar org.hsqldb.Server

Damit ist die Vorbereitung der serverseitigen JPA Infrastruktur abgeschlossen, die nächsten Schritte beinhalten die Einrichtung von JPA Provider, Verbindung zur Datenbank und welche Java Klassen wie auf die Datenbank abgebildet werden sollen.
(Zum besseren Vergleich zwischen Hibernate und JPA beinhaltet das Beispielprojekt auch die entsprechende native Hibernate Konfiguration und die Hibernate API Aufrufe in separaten Klassen. Mehr dazu in den folgenden Artikeln.)

Weitere Artikel:

1. JPA Einführung: Entity Klassen
2. Java Testing best practice: Projekt Organisation

Oracle Deutschland in Kooperation mit der buschmais GbR laden Sie zu einer kostenlosen eintägigen Veranstaltung ein, um Sie mit den zahlreichen Fähigkeiten von JPA 2.0, EclipseLink und dessen JPA-Implementierung vertraut zu machen. Außerdem möchten wir Ihnen darstellen, wie EclipseLink JPA innerhalb eines konkreten Projektes benutzt wurde, um eine JDO basierte Anwendung zu modernisieren.

Termine:
20.04.2010 Düsseldorf
21.04.2010 Frankfurt Dreieich
22.04.2010 München

Weitere Informationen zur Agenda, Anfahrt und Anmeldung finden Sie auf der Oracle Homepage unter:

http://www.oracle.com/global/de/community/adf/einladung_ELJPATage.html

oder auf den Seiten von buschmais:

http://www.buschmais.de/jpatage/

Weitere Artikel:

1. WJAX 2010: 15.-19. November
2. JAX Konferenz 2010
3. Software Freedom Day 2010: Review

Mike Keith and Merrick Schincariol authored a book which focuses on JPA 2, the Java persistence API which is now included in the Java EE 6 specification.

JPA has its origins in object relational mapping tools like hibernate, JDO or TopLink. While JPA was originally created as a standard for the Java enterprise stack, it did not take much time until it was was also used in the Java SE environment. JPA is easy to use and helpful if integrated into Desktop applications whenever object relational mapping  makes sense.

While JPA is covered in Java EE books as well, Pro JPA 2 only focuses on JPA and provides a profound coverage of the topic, attracting all kinds of developers. The books does not require previous knowledge of JPA 1 or other object relational mapping technology. A basic understanding of database systems, SQL and JDBC is required, but the required knowledge can be achieved by using Wikipedia or any introductory article.

The book motivates the usage of ORM (object relational mapping) software by showing the differences to JDBC, proprietary APIs, EJBs, and JDO. After reading the first pages, you are already able to write your first JPA 2 application, getting an overview of the various parts of JPA, configuration and running the application in a Java SE environment. This is especially useful for beginners, who are able to understand how the different parts operate  and are encouraged to try out the technology.

The third chapter provides a short introduction to Java EE and explains the role of JPA in the context of an enterprise application with an emphasis on transaction and dependency management. The following chapters focus on the many aspects of ORM, many UML diagrams help understanding the context. Advanced topics like caching, deployment, packaging and testing are covered as well, contributing to the good overall impression of the book.

The last chapter helps users who need to migrate from CMP entity beans, JDBC or other ORM solutions to JPA 2 and introduces related enterprise design patterns.

In a nutshell, the authors manage to satisfy both the needs of novice and experienced developers with a good introduction and an in-depth coverage.

I recommend the book to everyone who is using persistent storage in his applications. Persistence mapping eases development and JPA 2 is a mature and feature-rich API for the use in production and through various types of applications.

At various points the authors note the differences from previous JPA standard, so users who are forced to the old specification can be aware of incompatibilities.

If you are considering a migration from JPA 1 to JPA 2, you might want to know what you will gain:

What is new with JPA 2?

The main features included in the update from JPA are:

• Expanded object relational mapping functionality (support for collections of embedded objects, multiple levels of embedded objects, ordered lists)
• A criteria query API
• combinations of access types
• standardization of query-hints
• standardization of additional metadata to support DDL generation
• validation support

Title: Pro JPA 2: Mastering the Java™ Persistence API
Authors: Mike Keith, Merrick Schincariol
Amazon link: Pro JPA 2: Mastering the Java Persistence API

Weitere Artikel:

1. Review: Einstieg in Java
2. Software Freedom Day 2010: Review