Spring Data JPA — Specifications : composer des requêtes dynamiques avec la Criteria API

1📖 Glossaire — le vocabulaire de base

• Criteria API — API standard JPA pour construire une requête en Java, de façon typée, sans chaîne JPQL.
• CriteriaBuilder — fabrique de prédicats et d'expressions (equal, greaterThan, like, and, or, exists).
• CriteriaQuery — la requête SELECT en construction : type de résultat, distinct, orderBy, groupBy.
• Root / From — point d'entrée sur une entité. Root est la table principale. From est le type commun à Root et à une jointure.
• Predicate — une condition booléenne. Le WHERE d'une requête est un Predicate unique, souvent composé.
• JpaSpecificationExecutor — interface à ajouter au repository pour accepter des Specifications.
• Métamodèle — classes Order_, Customer_ générées à la compilation. Elles remplacent les chaînes "status" par des références typées.
• Fluent query — l'API findBy(spec, q -> ...). Elle permet de trier, limiter, projeter et choisir le type de résultat.
• Projection — lire seulement certaines colonnes vers une interface ou un record, au lieu de l'entité complète.
• Requête de count — seconde requête exécutée par Spring pour remplir le total d'une Page.

2Comment ça marche : un prédicat, pas une requête

Voici le chemin complet. On part du filtre saisi par l'utilisateur. On arrive au SQL exécuté.

flowchart LR
    A["Critères de recherche<br/>(status, customerId, dates...)"] --> B["OrderSpecs<br/>hasStatus(), forCustomer(), createdBetween()"]
    B --> C["Composition<br/>allOf(...) / and / or"]
    C --> D["JpaSpecificationExecutor<br/>findAll(spec, pageable)"]
    D --> E["CriteriaQuery<br/>SELECT o FROM Order o WHERE (spec)"]
    D --> F["CriteriaQuery<br/>SELECT count(o) FROM Order o WHERE (spec)"]
    E --> G[("SQL")]
    F --> G

Le contrat est très petit. Une spec reçoit trois objets. Elle renvoie un Predicate.

public interface Specification<T> extends Serializable {
    @Nullable
    Predicate toPredicate(Root<T> root, CriteriaQuery<?> query, CriteriaBuilder cb);
}

Un exemple minimal. Deux specs sur l'entité Order :

public class OrderSpecs {

    public static Specification<Order> hasStatus(OrderStatus status) {
        return (root, query, cb) -> cb.equal(root.get(Order_.status), status);   // ✓ métamodèle typé
    }

    public static Specification<Order> createdAfter(LocalDateTime date) {
        return (root, query, cb) -> cb.greaterThan(root.get(Order_.createdAt), date);
    }
}

Le repository. Il suffit d'ajouter JpaSpecificationExecutor :

public interface OrderRepository extends JpaRepository<Order, Long>, JpaSpecificationExecutor<Order> {
}

L'appel. On assemble deux specs avec and, puis on passe le résultat au repository :

List<Order> orders = orderRepository.findAll(
    hasStatus(OrderStatus.PAID).and(createdAfter(LocalDateTime.now().minusDays(7)))
);

Ce que fait Spring, dans l'ordre :

1. Il crée un CriteriaQuery qui sélectionne des Order.
2. Il appelle toPredicate sur la spec assemblée.
3. Il met le Predicate obtenu dans le WHERE.
4. Il exécute.

Le SQL produit :

select o.id, o.status, o.created_at, o.customer_id, ...   -- toutes les colonnes de l'entité
from orders o
where o.status = ? and o.created_at > ?

3Les quatre interfaces de la 4.x

Spring Data JPA 4.0 a réorganisé les Specifications en quatre interfaces. Toutes ont une méthode toPredicate. Ce qui change, ce sont les paramètres reçus.

PredicateSpecification : le bloc de base

Elle ne reçoit pas la requête. Elle ne peut donc pas faire de fetch. Elle ne peut pas non plus poser un distinct. En échange, elle marche partout : dans un SELECT, un UPDATE, un DELETE.

Elle reçoit un From, pas un Root. Pourquoi c'est important : un Root est la table principale. Un From est plus général, c'est la table principale ou une jointure. La même spec fonctionne donc sur les deux.

public class OrderSpecs {

    public static PredicateSpecification<Order> hasStatus(OrderStatus status) {
        return (from, cb) -> cb.equal(from.get(Order_.status), status);
    }

    public static PredicateSpecification<Order> forCustomer(Long customerId) {
        return (from, cb) -> cb.equal(from.get(Order_.customer).get(Customer_.id), customerId);
    }
}

Pour convertir une PredicateSpecification :

• en Specification : Specification.where(predicateSpec)
• en DeleteSpecification : DeleteSpecification.where(predicateSpec)

Souvent ce n'est même pas nécessaire. Les méthodes de JpaSpecificationExecutor acceptent directement une PredicateSpecification.

UpdateSpecification et DeleteSpecification : les écritures en masse

Une UpdateSpecification a deux parties. La partie SET dit quoi modifier. La partie WHERE dit sur quelles lignes. La partie WHERE est une PredicateSpecification, donc les mêmes specs que pour la lecture.

public static UpdateSpecification<Order> archiveOlderThan(LocalDateTime limit) {
    return UpdateSpecification.<Order>update((root, update, cb) -> {
            update.set(Order_.status, OrderStatus.ARCHIVED);   // ✓ la partie SET
        })
        .where(createdBefore(limit).and(hasStatus(OrderStatus.DELIVERED)));   // ✓ la partie WHERE, en PredicateSpecification
}

// Exécution
long updated = orderRepository.update(archiveOlderThan(LocalDateTime.now().minusYears(2)));
long deleted = orderRepository.delete(hasStatus(OrderStatus.CANCELLED));

La composition

Toutes les interfaces ont les mêmes combinateurs :

Specification<Order> spec = Specification.allOf(          // ✓ AND de toutes
    hasStatus(status),
    forCustomer(customerId),
    createdBetween(from, to)
);

Specification<Order> other = Specification.anyOf(a, b);   // ✓ OR de toutes
Specification<Order> negated = Specification.not(a);      // ✓ NOT
Specification<Order> chained = a.and(b).or(c);            // ✓ chaînage

allOf et anyOf acceptent une liste vide. Dans ce cas, le résultat est unrestricted(). Il matche tout.

unrestricted() : le remplaçant des specs nulles

Avant la 3.5, un filtre optionnel se codait souvent avec null. On écrivait Specification.where(null).and(...). Spring acceptait la spec nulle et l'ignorait.

Ce n'est plus possible. Specification.where(spec) a été dépréciée en 3.5. Elle a été retirée en 4.0. L'équipe Spring ne veut plus supporter les specs nulles.

Le remplaçant est unrestricted(). C'est une spec qui renvoie un prédicat null. Dans une composition, elle est ignorée :

unrestricted().and(other)   // ne considère que other
unrestricted().or(other)    // ne considère que other
not(unrestricted())         // équivaut à unrestricted()

Pour un filtre optionnel, le pattern devient :

public static Specification<Order> hasStatusIfPresent(@Nullable OrderStatus status) {
    return status == null
        ? Specification.unrestricted()                                      // ✓ pas de null
        : (root, query, cb) -> cb.equal(root.get(Order_.status), status);
}

4Écrire des specs proprement

Une classe de specs statiques par entité

Une méthode statique par règle métier. Le nom de la méthode est le nom de la règle. Les specs deviennent un vocabulaire que tout le monde lit.

public final class OrderSpecs {

    private OrderSpecs() {}

    public static Specification<Order> hasStatus(OrderStatus status) {
        return (root, query, cb) -> cb.equal(root.get(Order_.status), status);
    }

    public static Specification<Order> forCustomer(Long customerId) {
        return (root, query, cb) -> cb.equal(root.get(Order_.customer).get(Customer_.id), customerId);
    }

    public static Specification<Order> createdBetween(LocalDateTime from, LocalDateTime to) {
        return (root, query, cb) -> cb.between(root.get(Order_.createdAt), from, to);
    }

    public static Specification<Order> referenceContains(String fragment) {
        return (root, query, cb) ->
            cb.like(cb.lower(root.get(Order_.reference)), "%" + fragment.toLowerCase() + "%");
    }

    public static Specification<Order> containsSku(String sku) {
        return (root, query, cb) -> {
            Subquery<Long> sub = query.subquery(Long.class);              // ✓ exists, pas de join
            Root<OrderLine> line = sub.from(OrderLine.class);
            sub.select(cb.literal(1L))
               .where(cb.equal(line.get(OrderLine_.order), root),
                      cb.equal(line.get(OrderLine_.sku), sku));
            return cb.exists(sub);
        };
    }
}

Assembler depuis un objet de critères

Le service reçoit un record de critères. Tous les champs sont optionnels. Pour chaque champ, la règle est simple : s'il est rempli, on ajoute la spec ; sinon, on met unrestricted(). Il n'y a aucun null dans l'assemblage.

public record OrderSearchCriteria(
    @Nullable OrderStatus status,
    @Nullable Long customerId,
    @Nullable LocalDateTime from,
    @Nullable LocalDateTime to,
    @Nullable String reference,
    @Nullable String sku
) {}

@Service
public class OrderSearchService {

    private final OrderRepository orderRepository;

    public Page<Order> search(OrderSearchCriteria c, Pageable pageable) {
        Specification<Order> spec = Specification.allOf(
            c.status()     != null ? hasStatus(c.status())                     : unrestricted(),
            c.customerId() != null ? forCustomer(c.customerId())               : unrestricted(),
            c.from() != null && c.to() != null ? createdBetween(c.from(), c.to()) : unrestricted(),
            c.reference()  != null ? referenceContains(c.reference())          : unrestricted(),
            c.sku()        != null ? containsSku(c.sku())                      : unrestricted()
        );
        return orderRepository.findAll(spec, pageable);
    }
}

Le métamodèle : obligatoire, pas optionnel

Sans métamodèle, on écrit root.get("status"). C'est une chaîne. Si on écrit "statut" par erreur, le code compile. L'erreur ne sort qu'à l'exécution, et seulement quand ce filtre est activé.

Avec le métamodèle, on écrit root.get(Order_.status). Order_ est une classe générée. Si le champ n'existe pas, javac refuse de compiler.

<annotationProcessorPaths>
    <path>
        <groupId>org.hibernate.orm</groupId>
        <artifactId>hibernate-processor</artifactId>   <!-- ✓ Hibernate 7 ; hibernate-jpamodelgen en Hibernate 6 -->
        <version>${hibernate.version}</version>
    </path>
</annotationProcessorPaths>

5Exécuter une spec

JpaSpecificationExecutor propose deux familles de méthodes.

Les méthodes directes

Optional<Order> one   = orderRepository.findOne(spec);          // IncorrectResultSizeDataAccessException si > 1
List<Order> all       = orderRepository.findAll(spec);
List<Order> sorted    = orderRepository.findAll(spec, Sort.by("createdAt").descending());
Page<Order> page      = orderRepository.findAll(spec, PageRequest.of(0, 20));
long count            = orderRepository.count(spec);
boolean exists        = orderRepository.exists(spec);
long deleted          = orderRepository.delete(spec);           // depuis 3.0
long updated          = orderRepository.update(updateSpec);     // depuis 4.0

La fluent API : findBy(spec, q -> ...)

Les méthodes directes ont des limites. Elles renvoient toujours des entités. Elles ne savent pas limiter à N résultats. Elles ne savent pas parcourir un gros volume par paquets.

La fluent API lève ces limites. On passe la spec, puis une fonction qui décrit ce qu'on veut : projection, limite, tri, scroll, stream.

// Page projetée, triée
Page<OrderSummary> page = orderRepository.findBy(spec,
    q -> q.as(OrderSummary.class)
          .page(PageRequest.of(0, 20, Sort.by("createdAt").descending())));

// Le plus récent
Optional<Order> latest = orderRepository.findBy(spec,
    q -> q.sortBy(Sort.by("createdAt").descending()).first());

// Stream pour un export (à fermer)
try (Stream<Order> stream = orderRepository.findBy(spec, FluentQuery.FetchableFluentQuery::stream)) {
    stream.forEach(exporter::write);
}

// Keyset scrolling
Window<Order> window = orderRepository.findBy(spec,
    q -> q.sortBy(Sort.by("id")).limit(100).scroll(ScrollPosition.keyset()));

6Jointures et collections

C'est ici que se cachent la plupart des bugs de Specification.

join vs fetch

Il y a deux façons de joindre une table dans une spec. Elles ne servent pas au même besoin.

• root.join("lines") sert à filtrer sur les lignes. Les lignes ne sont pas chargées.
• root.fetch("lines") sert à charger les lignes en même temps que les commandes.

// Filtrer sur les lignes : join
(root, query, cb) -> cb.equal(root.join(Order_.lines).get(OrderLine_.sku), sku)

// Charger les lignes avec les commandes : fetch
(root, query, cb) -> {
    root.fetch(Order_.lines, JoinType.LEFT);
    return cb.conjunction();
}

Le join sur une collection duplique les lignes

Prenons une commande avec trois lignes qui ont toutes le SKU cherché. Avec un join, la commande apparaît trois fois dans le résultat. Une fois par ligne.

Le réflexe est d'ajouter query.distinct(true). Ça corrige la liste. Mais ça a deux effets de bord :

• la requête de count change aussi (voir section 7) ;
• Hibernate doit dédupliquer en mémoire.

Le pattern exists : la bonne réponse pour filtrer sur une collection

À la place du join, on écrit une sous-requête. Elle dit : "il existe au moins une ligne de cette commande avec ce SKU".

public static Specification<Order> containsSku(String sku) {
    return (root, query, cb) -> {
        Subquery<Long> sub = query.subquery(Long.class);
        Root<OrderLine> line = sub.from(OrderLine.class);
        sub.select(cb.literal(1L))
           .where(cb.equal(line.get(OrderLine_.order), root),   // ✓ corrélation avec la commande
                  cb.equal(line.get(OrderLine_.sku), sku));
        return cb.exists(sub);
    };
}

SQL produit :

select o.* from orders o
where exists (select 1 from order_line l where l.order_id = o.id and l.sku = ?)

Ce qu'on gagne :

• Pas de doublon. La commande apparaît une seule fois.
• Pas de distinct.
• La requête de count reste juste.
• Deux specs composées gardent leur sens. containsSku("A").and(containsSku("B")) donne deux exists indépendants. Cela veut dire : la commande contient A, et la commande contient B. C'est bien ce qu'on voulait.

Les specs composées ne partagent pas leurs jointures

Prenons deux specs. La première fait root.join(lines) et filtre sur le SKU. La seconde fait aussi root.join(lines) et filtre sur la quantité. On les combine avec and.

Chaque spec ne connaît pas l'autre. Chacune crée sa propre jointure. Le SQL contient donc order_line deux fois : l1 et l2.

Conséquence : la condition sur le SKU regarde l1. La condition sur la quantité regarde l2. Rien n'oblige l1 et l2 à être la même ligne. Une commande avec une ligne "SKU A, quantité 1" et une autre ligne "SKU B, quantité 50" est retournée. Ce n'est pas ce qu'on voulait. En plus, la requête est plus lente, car les lignes sont combinées entre elles (produit cartésien).

Si le besoin est bien "une même ligne qui satisfait les deux conditions", il y a deux solutions :

• écrire une seule spec qui pose les deux conditions sur la même jointure ;
• utiliser un helper qui réutilise une jointure déjà créée.

static <X, Y> Join<X, Y> joinOnce(From<?, X> from, SingularAttribute<? super X, Y> attr) {
    return joinOnce(from, attr.getName());
}

@SuppressWarnings("unchecked")
static <X, Y> Join<X, Y> joinOnce(From<?, X> from, String attribute) {
    return (Join<X, Y>) from.getJoins().stream()
        .filter(j -> j.getAttribute().getName().equals(attribute))
        .findFirst()
        .orElseGet(() -> from.join(attribute));   // ✓ une seule jointure par attribut
}

7Pagination : la requête de count dérivée

Une Page a besoin de deux choses : les lignes de la page, et le nombre total de lignes. Spring fait donc deux requêtes. La première lit les données. La seconde fait un count.

Le point important : votre spec est appelée deux fois. Une fois pour la requête de données. Une fois pour la requête de count. C'est la même lambda. Mais la requête reçue en paramètre n'est pas la même. Dans le second cas, query renvoie un Long.

sequenceDiagram
    participant S as Service
    participant R as SimpleJpaRepository
    participant Spec as Specification
    participant DB as PostgreSQL
    S->>R: findAll(spec, pageable)
    R->>Spec: toPredicate(root, CriteriaQuery<Order>, cb)
    Spec-->>R: predicate
    R->>DB: select o.* ... where (predicate) order by ... limit 20 offset 0
    DB-->>R: 20 lignes
    R->>Spec: toPredicate(root, CriteriaQuery<Long>, cb)
    Note over Spec: même lambda, requête différente
    Spec-->>R: predicate
    R->>DB: select count(o) ... where (predicate)
    DB-->>R: total
    R-->>S: Page<Order>

Tout ce que vous faites dans la spec s'applique donc aussi au count. C'est la source des trois pièges qui suivent.

Piège 1 : un fetch fait échouer le count. Un fetch charge une collection. Sur une requête count, ça n'a pas de sens. Hibernate refuse avec QueryException: query specified join fetching, but the owner of the fetched association was not present in the select list.

La parade : tester le type de résultat. Si c'est Long, on est sur le count, et on ne fait pas le fetch.

public static Specification<Order> withLines() {
    return (root, query, cb) -> {
        if (query.getResultType() != Long.class && query.getResultType() != long.class) {   // ✓ pas sur le count
            root.fetch(Order_.lines, JoinType.LEFT);
        }
        return cb.conjunction();
    };
}

Piège 2 : distinct change le count. query.distinct(true) donne select count(distinct o). Le résultat est juste. Mais la requête est plus lente. Et avec exists, ce distinct est inutile.

Piège 3 : un orderBy dans la spec est écrasé. Si le Pageable contient un tri, Spring appelle query.orderBy(...) après la spec. Ce tri remplace celui de la spec. Le tri appartient au Pageable ou au Sort, pas à la spec.

8Projeter vers un DTO

Par défaut, findAll(spec) renvoie des entités complètes. Prenons une liste qui affiche deux colonnes. L'entité en a trente. On lit trente colonnes pour en montrer deux. C'est du gaspillage : plus de données transférées, plus de mémoire, et un dirty checking inutile.

Option 1 : la projection de la fluent API

On déclare une interface avec seulement les champs voulus. On la passe à as(...).

public interface OrderSummary {
    Long getId();
    String getReference();
    OrderStatus getStatus();
}

Page<OrderSummary> page = orderRepository.findBy(spec,
    q -> q.as(OrderSummary.class).page(pageable));

Depuis Spring Data JPA 3.5, cette projection ne lit que les propriétés de l'interface. Avant, elle chargeait l'entité entière puis la convertissait.

Une limite reste. Une propriété imbriquée, comme getCustomer().getName(), déclenche la jointure et charge le sous-objet complet.

Option 2 : la Criteria manuelle qui réutilise la spec

Parfois il faut choisir les colonnes exactement. Par exemple une colonne d'une table jointe. Ou un agrégat. Dans ce cas, on sort du repository.

La spec reste utile. On l'appelle soi-même pour obtenir le WHERE.

@Repository
public class OrderQueryRepository {

    private final EntityManager em;

    public List<OrderSummaryDto> search(Specification<Order> spec) {
        CriteriaBuilder cb = em.getCriteriaBuilder();
        CriteriaQuery<OrderSummaryDto> q = cb.createQuery(OrderSummaryDto.class);
        Root<Order> root = q.from(Order.class);

        q.select(cb.construct(OrderSummaryDto.class,
                    root.get(Order_.id),
                    root.get(Order_.reference),
                    root.get(Order_.customer).get(Customer_.name)))   // ✓ colonne d'une jointure
         .where(spec.toPredicate(root, q, cb));                      // ✓ réutilise la spec

        return em.createQuery(q).getResultList();
    }
}

public record OrderSummaryDto(Long id, String reference, String customerName) {}

Le SQL ne lit que trois colonnes. Aucune entité n'entre dans le contexte de persistance.

9Les limites propres aux Specifications

Beaucoup d'articles reprochent aux Specifications des défauts qui viennent en réalité de JPA ou d'Hibernate. Il faut séparer les deux.

Ce qui est propre aux Specifications

1. Une spec ne produit qu'un WHERE. Le SELECT, le GROUP BY, les agrégats et le HAVING ne sont pas dans son périmètre. Pour une somme par client, il faut repasser par EntityManager.
2. Les projections sont récentes et partielles. Elles marchent depuis 3.5 pour les propriétés de premier niveau. Une propriété imbriquée charge le sous-objet complet. Avec @Query et select new Dto(...), on choisit tout.
3. La requête de count est dérivée de la même spec. C'est l'origine des pièges fetch, distinct et orderBy de la section 7. Avec @Query, on écrit countQuery soi-même.
4. Les specs composées ne partagent pas leurs jointures. Deux specs qui joignent la même collection donnent un produit cartésien. En JPQL, on écrit une seule jointure.
5. Les erreurs n'apparaissent qu'à l'exécution de la combinaison fautive. Une méthode dérivée ou un @Query est validé au démarrage de l'application. Une spec avec un chemin faux ne casse que quand ce filtre est activé. Le métamodèle corrige ça pour les noms de propriétés. Il ne corrige pas la logique.
6. Le SQL final dépend de l'assemblage. On ne peut pas lire la requête dans le code. Pour vérifier qu'un index est utilisé, il faut logger le SQL et tester chaque combinaison de filtres.
7. Les fonctionnalités avancées demandent un cast Hibernate. CTE, window functions, opérateurs jsonb ou ltree : la Criteria API standard ne les connaît pas. Il faut caster en HibernateCriteriaBuilder, ou passer par cb.function(...). C'est verbeux et couplé à Hibernate.
8. La sémantique de composition a bougé. where(spec) retirée en 4.0. unrestricted() ajoutée en 3.5.2. not(unrestricted()) corrigée en 3.5.5. Du code 3.x peut changer de comportement.
9. Le pattern "spec générique" ouvre des champs non prévus. Voir section 10.

Ce qui n'est pas propre aux Specifications

10Sécurité : la spec générique

Le pattern tentant : construire une spec depuis des paramètres HTTP libres, par exemple ?field=status&op=eq&value=PAID.

// ❌ n'importe quelle colonne de l'entité devient filtrable
public static <T> Specification<T> generic(String field, String value) {
    return (root, query, cb) -> cb.equal(root.get(field), value);
}

Ce n'est pas une injection SQL. Les valeurs passent en paramètres. La base est protégée. Le problème est ailleurs : le nom du champ vient de l'appelant. Il peut donc mettre n'importe quel nom de colonne de l'entité.

Exemple. L'entité a un champ internalMargin que l'API n'expose jamais. L'appelant envoie ?field=internalMargin&op=gt&value=30. Il reçoit la liste des commandes dont la marge dépasse 30. Il n'a jamais vu la colonne, mais il vient de lire son contenu. En répétant avec d'autres valeurs, il retrouve la marge exacte de chaque commande. Même chose avec passwordHash ou customer.email. Et un chemin comme a.b.c peut déclencher des jointures que personne n'a prévues.

La parade : une liste blanche. On écrit soi-même les chemins autorisés. L'appelant ne fournit qu'une clé.

private static final Map<String, Function<Root<Order>, Path<?>>> FILTERABLE = Map.of(
    "status",    root -> root.get(Order_.status),
    "reference", root -> root.get(Order_.reference),
    "customer",  root -> root.get(Order_.customer).get(Customer_.id)
);

public static Specification<Order> filter(String field, Object value) {
    Function<Root<Order>, Path<?>> path = FILTERABLE.get(field);
    if (path == null) {
        throw new IllegalArgumentException("Filtre non autorisé : " + field);   // ✓ refus explicite
    }
    return (root, query, cb) -> cb.equal(path.apply(root), value);
}

11Tableau de synthèse : quelle approche pour quelle requête

Quand choisir :

• Méthode dérivée : une requête fixe avec un ou deux paramètres. C'est le cas le plus courant.
• @Query JPQL : une requête fixe plus complexe. Une projection sur plusieurs tables. Un agrégat. Un countQuery maîtrisé.
• Specification : un écran de recherche avec des filtres optionnels combinables, sur une entité, sans agrégat. Avec exists pour les collections et un helper de jointure.
• Query by Example : un prototype ou un filtre d'égalité simple. Pas de >, pas de between, pas de collection.
• Criteria manuelle ou jOOQ : une requête dynamique et complexe. Un export volumineux. Du SQL spécifique PostgreSQL. La spec peut fournir le WHERE à la Criteria manuelle.

Sources

• Spring Data JPA Reference — Specifications (4.1.1) — documentation officielle : les quatre interfaces, la composition, la fluent API et ses méthodes intermédiaires et terminales
• Javadoc Specification (4.1) — sémantique de unrestricted(), allOf, anyOf, not
• Javadoc PredicateSpecification (4.0) — contrat sur From, élision des specs null
• Javadoc JpaSpecificationExecutor (4.1) — update, delete, findBy, et la note sur le contexte de persistance non synchronisé
• Issue #3893 — Specification.where(spec) is deprecated — origine de la dépréciation et de unrestricted()
• Issue #3942 — Backport Specification.unrestricted() to 3.5.x — arrivée de unrestricted() en 3.5.2
• PR #4024 — Consistent handling of unrestricted() in not(..) — changement de sémantique de not(unrestricted()) en 3.5.5