Mit der Jakarta Version 11 wird es auch im Bereich von Jakarta Persistence einige Neuerungen geben. Ich möchte euch in diesem Beitrag einmal vorab einige dieser Neuerungen vorstellen.
Programmatische Konfiguration
Möchte man Jakarta Persistence in seiner Anwendung konfigurieren, hatte man bisher nur die Möglichkeit über die persistence.xml bzw. in Runtime-Frameworks über die application.properties Datei diese Konfiguration festzulegen. Mit Jakarta Persistence 3.2 kommt eine weitere Möglichkeit zur Konfiguration hinzu. Dazu wurde die Klasse PersistenceConfiguration erschaffen, mit der es möglich ist direkt in Java die Konfiguration zu erstellen. In Kombination mit dem Startup-Event, dass in Jakarta Context and Dependency bereits in Version 4.0 (JEE 10) eingeführt wurde, lässt sich über einen Producer ein entsprechender EntityManager erzeugen.
@ApplicationScoped
public class PersistenceConfig {
EntityManagerFactory emf;
void init(@Observes Startup event) {
emf = new PersistenceConfiguration()
.name("Bookshop")
.nonJtaDataSource("java:global/jdbc/BookshopData")
.managedClass(Person.class)
.property(PersistenceConfiguration.LOCK_TIMEOUT, 5000)
.createEntityManagerFactory();
}
@Produces
EntityManager createEntityManager() {
return emf.createEntityManager();
}
}
Enum Mappings
Die Verwendung von Enums in Entities war bisher auf das Mapping der Werte in Form von Ordinal oder String beschränkt. Nun wurde eine neue Annotation @EnumeratedValue
definiert, mit der man die Attribute des Enum auf die Datenbankspalten mappen kann.
enum Status {
NEW(0), IN_PROGRESS(1), DONE(2), NOT_VALID(-1);
@EnumeratedValue
final int value;
Status(int value) {
this.value = value;
}
}
Eingebettete Records
Die dritte und letzte Neuerung, die ich euch vorstellen möchte betrifft die Möglichkeit zur Verwendung von Records in Jakarata Persistence. Mit der neuen Version ist es nun möglich auch Records per @Embeddable oder mit @IdClass zu annotieren. So lässt sich beispielsweise eine Adresse mit folgendem Record sehr einfach umsetzen.
@Embeddable
public record Address(String street, String city, String state, String zip) {
}
In Verbindung mit der Einbindung von Records werden damit auch folgende Restriktionen gelöst:
- Entity- und Eingebettete-Klassen können nun auch statische innere Klassen sein
- Primärschlüssel-Klassen müssen nicht länger
public
und serialisierbar sein