Six ans et demi après la sortie d'Hibernate ORM 5.0, Red Hat a publié la version 6.0 de son produit phare, Hibernate ORM, l'utilitaire populaire de persistance de type object-relational mapping. Les nouvelles fonctionnalités importantes incluent une migration vers la spécification Jakarta Persistence 3.0, des améliorations de performances vers JDBC, ainsi que la traduction HQL et la traduction des criterias. Avec cette version, Hibernate nécessite au minimum Java 11.
Avec Hibernate 6.0, la persistance Java n'est plus définie par l'API Java Persistence de Java EE, mais plutôt par la spécification Jakarta Persistence 3.0 de Jakarta EE. Cela signifie que le package javax.persistence n'est plus disponible. Les développeurs doivent maintenant importer le package jakarta.persistence dans leur code Java. Un exemple d'entité ressemblerait à ceci :
import jakarta.persistence.Column;
import jakarta.persistence.Entity;
import jakarta.persistence.GeneratedValue;
import jakarta.persistence.Id;
import jakarta.persistence.Table;
import jakarta.persistence.Temporal;
import jakarta.persistence.TemporalType;
import java.util.Date;
import org.hibernate.annotations.GenericGenerator;
@Entity
@Table(name = "EVENTS")
public class Event {
@Id
@GeneratedValue(generator = "increment")
@GenericGenerator(name = "increment", strategy = "increment")
private Long id;
private String title;
@Temporal(TemporalType.TIMESTAMP)
@Column(name = "EVENT_DATE")
private Date date;
public Event() {
// this form used by Hibernate
}
// getter methods
// setter methods
}
L'API Java JDBC fournit ResultSet, une interface pour représenter le résultat de la base de données généralement généré en exécutant une instruction qui interroge la base de données. Il existe deux manières d'extraire des données, lues par nom et lues par position, à partir d'un ensemble de résultats. Avec cette version, la lecture à partir d'une instance d'un ResultSet passe de la lecture par nom à la lecture par position. À ce sujet, le lead software engineer de Red Hat et le lead developer d'Hibernate ORM Steve Ebersole a mentionné dans la release notes :
Il y a quelques années, autour de la version 5.4, nous avons travaillé avec l'incroyable équipe de performance de Red Hat pour tirer encore plus de performances d'Hibernate ORM. Ce travail faisait partie d'un effort plus vaste visant à améliorer les performances de WildFly.
En fin de compte, le facteur limitant des améliorations supplémentaires dans Hibernate était notre approche consistant à lire les valeurs d'un ResultSet JDBC par nom plutôt que par position. Pour chaque pilote JDBC, la lecture par nom est plus lente.
En d'autres termes, cela suggère que la lecture par position est plus rapide que la lecture par nom, comme expliqué par le Responsable du pilote JDBC de Firebird Mark Rotteveel dans ce Message StackOverflow :
Les valeurs des lignes seront généralement stockées dans un tableau ou une liste car cela correspond le plus naturellement à la façon dont les données sont reçues du serveur de base de données. De ce fait, la récupération des valeurs par index sera la plus simple.
D'un autre côté, rechercher par nom de colonne demande plus de travail. Les noms de colonne doivent être traités sans tenir compte de la casse, ce qui a un coût supplémentaire, que vous normalisiez en utilisant des minuscules ou des majuscules, ou que vous utilisiez une recherche insensible à la casse à l'aide d'un TreeMap.
Les modifications apportées à la lecture par position dans un ResultSet ont également entraîné des modifications dans le système de type Hibernate. Il supprime toutes les approches basées sur des chaînes pour spécifier les types, y compris les annotations obsolètes @AnyMetaDef, @AnyMetaDefs, @TypeDef et @TypeDefs. Hibernate 6.0 redessine également ses annotations revendiquant une meilleure sécurité de type. Les développeurs souhaitant voir les modifications peuvent se référer au guide de l'utilisateur pour les détails de mapping du modèle de domaine.
En plus de cela, en tant qu'effet secondaire de la lecture par position dans Hibernate 6.0, les requêtes SQL select générées ne doivent plus créer d'alias de colonnes nommées, ce qui rend le SQL généré beaucoup plus lisible.
| Pre-Hibernate 6.0 | Hibernate 6.0 |
select event0_.id as id1_0_, |
select e1_0.id,e1_0.event_date,e1_0.title |
Hibernate utilise HQL, un langage de requête similaire à SQL, sauf que HQL est orienté objet et comprend des notions telles que l'héritage, le polymorphisme et l'association.
HQL est écrit à l'aide d'ANTLR, un puissant analyseur générateur pour lire, traiter, exécuter ou traduire du texte structuré ou des fichiers binaires. Cette version passe d'ANTLR 2 à ANTLR 4, ce qui rend HQL plus efficace, comme indiqué dans les release notes.
Un autre changement important dans Hibernate 6.0 est le modèle de requête sémantique (SQM), un nouvel analyseur de requêtes pour traiter à la fois les requêtes HQL et criteria, prétendant fournir de meilleures performances que les capacités de requête Hibernate HQL précédentes.
Cette version supprime l'ancienne API Criteria d'Hibernate et la prise en charge des requêtes par criteria est désormais offerte uniquement via l'API Jakarta Persistence. Une nouvelle annotation @Incubating a également été introduite, destinée à avertir les utilisateurs qu'un contrat particulier peut changer à l'avenir.
Cette version offre de nombreuses autres nouvelles fonctionnalités et modifications internes. Les artefacts Maven sont déjà publiés dans Maven Central, donc Hibernate 6.0 est prêt à être inclus dans n'importe quelle application Java. Les développeurs intéressés par la migration vers Hibernate 6.0 peuvent lire le guide de migration. Les nouveaux développeurs Hibernate peuvent tirer parti du Guide de démarrage Hibernate, couvrant la plupart des concepts et API destinés aux utilisateurs.