Bojo Blog

Développement avec l’IA, retour d’expérience

2025-06-30T00:00:00+00:00

J’ai beaucoup hésité avant de me lancer…

D’une part, le sujet est vraiment partout, et il me semble plus ancré que les hypes précédentes, comme le metaverse ou les cryptomonnaies. C’est difficile de l’ignorer quand on est développeur. D’autre part, le sujet soulève tellement de questions environnementales et sociétales. C’est irresponsable de s’y engager dans son état actuel.

Vous aurez compris que je parle d’IA générative, plus précisément de l’utilisation d'IA générative dans le développement Java. Je vais vous expliquer comment j’ai abordé le sujet et ce que j’en retire pour le moment. Et comme ça bouge très vite, notez bien la date de publication du billet : c’est fin juin 2025. Il n’est pas impossible que je change d’avis pendant l’été !

Mes premiers pas

Dans des projets précédents, mes collègues m’ont poussé à utiliser des outils d’IA générative pour certaines tâches de développement. A l’époque, début 2023, je n’avais pas d’outil spécifique pour le développement et j’utilisais ChatGPT.

Le premier cas d’usage qu’on m’a demandé d’explorer, c’était la génération de documentation technique. Son mode de fonctionnement par chat dans le navigateur limitait fortement les possibilités puisqu’on lui transmet les informations par copier/coller. Il n’avait pas de contexte dans lequel replacer chaque classe. Bref, c’était une impasse.

Du coup, on s’est rabattus sur la génération de Javadoc. Mais là aussi, sans contexte la génération se limitait à dire que getLabel() retournait le label et que buildProduct(…) construisait un produit. Bref, c’était digne de Captain Obvious.

Le second cas d’usage était l'exploration technique. Par exemple, on avait besoin de projections un peu élaborées avec Hibernate. Ses réponses inventaient des classes dans Hibernate et tournaient en rond quand j’essayais de recadrer. Bref, j’ai perdu pas mal de temps.

J’ai retenté ma chance début 2025. D’abord parce que l’écosystème a changé avec des outils spécialisés et adaptés au métier de développeurs. Et plus particulièrement parce que Jetbrains a une offre intégrée dans son IDE que j’utilise depuis pas mal d’années.

Ensuite parce que je travaille sur un projet qui se prête à cette expérimentation, avec une équipe limitée à un seul développeur, avec une planification un peu chaotique et des spécifications assez instables.

L’IA avec IntelliJ

Le projet a commencé en 2024 sans outil d’IA, mais avec mon IDE habituel, IntelliJ IDEA. Pour une transition douce, je souhaitais continuer avec celui-ce plutôt que de basculer sur des outils à la mode.

IntelliJ propose propose quatre niveaux d’intégration de l’IA :

avec la complétion de code,
via des menus contextuels,
en chat via un assistant IA,
en interaction complète dans le code via un agent.

Complétion

La première utilisation de l’IA dans IntelliJ se fait assez facilement. C’est juste un enrichissement de la complétion, lorsqu’on fait CTRL+SPACE. Pour simplifier, avant elle proposait un mot (variable, méthode,…) maintenant c’est une ligne complète ou quelques lignes.

La valeur ajoutée est limitée, mais avec peu d’inconvénients. Ça n’implique pas de changement dans la façon de travailler. Et ça utilise un petit modèle spécialisé, en local (JetBrains Mellum, 100 Mo / langage).

La variante plus poussée consiste à écrire un commentaire dans le code. L’IA complète le commentaire et propose une série de lignes de code pour l’implémenter.

J’ai du mal avec ce mode, je trouve ça un peu déstabilisant, car ça génère souvent trop de choses par rapport à mon souhait. Tyîquement sur l’exemple ci-dessus, pourquoi est-ce que ça ajoute System.err.println(…) ? Et j’ai du mal à régler mon commentaire/prompt pour obtenir le bon résultat.

Actions d’IA

Le menu "Generate with AI" (ou son raccourci) est un peu plus explicite. Ça ouvre une zone de prompt et génère directement du code à l’emplacement du curseur. Par contre, c’est un peu moins fluide, avec plus de temps de réflexion, signe que ça passe par un modèle externe.

Le menu contextuel "IA Actions" propose aussi de générer des tests unitaires, de générer de la documentation, d’expliquer du code ou de proposer un refactoring. J’ai peu utilisé ces actions, je n’ai donc pas encore de recul.

Chat

Avec le chat, on revient à un mode de fonctionnement plus classique. L’avantage avec un chat traditionnel, c’est qu’il est intégré à l’IDE. Et cette intégration est sa valeur ajoutée puisqu’il peut utiliser le code du projet comme contexte.

S’il peut lire le code du projet, il n’y écrit rien. Il donne ses réponses dans le chat avec du code et des explications. Honnêtement, je ne lis presque jamais les explications, c’est le code qui m’intéresse.

Pour cette fonctionnalité, on utilise un modèle classique (GPT, Claude, Gemini,…) hébergé par Jetbrains ou un modèle auto-hébergé.

J’utilise ceci pour des explorations, pour trouver des solutions avec des librairies que je connais peu. Le meilleur exemple, c’était pour une personnalisation un peu fine de graphiques avec jfreechart.

Junie

Le mode le plus intégré, c’est Junie. C’est aussi le mode hype et le plus controversé.

Le point de départ est aussi un chat, mais avec cette fonctionnalité un agent intervient directement sur le code. Evidemment, tous les changements sont détaillé dans le chat et accompagnés d’explications. Et chacune peut être acceptée ou refusée via un diff, comme avec git.

La valeur ajoutée se situe dans l’utilisation d’un fichier de guidelines. Il ressemble aux guidelines qu’on écrirait pour embarquer un humain dans le projet. Comme j’ai commencé à utiliser Junie bien après le début du projet, j’ai fait générer le fichier par Junie à partir du code existant.

J’avais quelques réticences, mais elles se sont estompées au fur et à mesure. Aujourd’hui, j’utilise Junie pour générer du code classique, comme du simple Find/Update/Create/Remove. Il est aussi assez efficace pour générer de la documentation technique ou des tests unitaires. Pour ces derniers, je n’ai pas encore trouvé le bon réglage car ils sont trop verbeux à mon goût.

Ce qui me perturbe le plus au quotidient, c’est assez lent. Il faudrait que je trouve une occupation pendant qu’il travaille, sans que ça me sorte du sujet. C’est vraiment différent des mes habitudes de travail.

Qualité du code

Il arrive régulièrement que le code généré ne compile pas ou qu’il faille pas mal d’itérations pour que les tests passent au vert. Quand on parle de génération, ça ne se limite vraiment pas à cliquer sur un bouton. Ça peut prendre du temps. Ça peut aussi être énervant de le voir patauger, il faut de la patience.

Dans tous les modes, le code a généralement des défauts, avec des portions pas optimisées et souvent trop verbeuses. Dans tous les cas, ça demande une surveillance et de retouches.

Conclusion

Ces quelques semaines d’expérimentation ont bien changé mon point de vue. L’IA générative apporte probablement un gain de productivité, sans que je puisse le quantifier.

Elle apporte une plus-value dans la production de code classique du projet (FUCR) et pour des parties classiques pour d’autres, mais pas pour moi. Elle n’est pas à l’aise dans les parties plus pointues techniquement, comme des personnalisations fines du framework.

Je pense que ce sont des outils intéressants à condition que le développeur reste aux commandes. Dans l’état actuel, je ne laisserais pas un agent libre de proposer ses pull requests car ça impliquerait trop de travail de revue de code.

Évidemment, mes conclusions peuvent être remises en question dans les prochaines semaines.

Il y a aussi une question subsidiaire. Est-ce qu’on peut considérer le gain suffisant par rapport aux coûts environnementaux et sociétaux ? La réponse est certainement différente entre les fonctionnalités à petit modèle local et celle à gros modèle généraliste.

P.S. :

Le billet a été totalement écrit par un humain.
Les dessins d’illustration ont été générés par une IA et modifiés par un humain.

Afficher un historique avec Hibernate Envers

2024-09-08T00:00:00+00:00

Sur un projet en cours, on stocke l’historique complet des modifications sur les entités. Le projet utilise les frameworks classiques: Spring Boot 3 et JPA / Hibernate 6. Nous avons ajouté Hibernate Envers pour stocker les changements dans des tables d’audit.

@Entity
@Audited(withModifiedFlag = true)
public class Product extends AbstractEntity<UUID> {
    ...
}

La façon d’enregistrer ces modifications est bien documentée, je n’y reviendrai pas. Pour ce projet, nous avons voulu ajouter une façon générique d’afficher l’historique des changements pour chaque instance d’entité.

Query API d’Envers

Envers a une API de requêtage qui permet d’interroger les tables d’audit sans se préoccuper de la façon dont les données sont stockées. Par exemple, pour avoir l’état d’une instance de l’entité Document à une certaine révision, on crée une query à laquelle on passe l’identifiant et le numéro de révision.

AuditQuery query = AuditReaderFactory.get(entityManager)
        .createQuery()
        .forEntitiesAtRevision(Customer.class, revNumer)
        .add(AuditEntity.id().eq(id));
Document document = (Document) query.getSingleResult();

L’API permet de faire pas mal de choses, plus ou moins complexes. La capacité qui nous intéresse c’est d’avoir une liste des révisions d’une instance d’entité, avec les changements qui ont été réalisés sur pour chaque révision.

AuditQuery auditQuery = AuditReaderFactory.get(entityManager)
        .createQuery()
        .forRevisionsOfEntityWithChanges(entityClass, true)
        .add(AuditEntity.id().eq(id))
        .addOrder(AuditEntity.revisionNumber().desc());
List<Object[]> list = auditQuery.getResultList();

La première chose qui saute aux yeux, c’est le faible niveau de typage. Pour l’entité simple, il a fallu transtyper le résultat et pour la liste des révisions, c’est pire puisque chaque ligne du résultat est un tableau d’objets avec:

à l’index 0, il y a l’entité, dans son état pour la révision,
à l’index 1, il y a la révision (l’entité, pas juste le n°)
à l’index 2, il y a le type de révision (ADD, MOD, DEL)
à l’index 3, il y a la liste des propriétés qui ont changé.

Amélioration simple

La première amélioration qu’on a introduite a été de transformer ce tableau d’objets en record, pour avoir une structure lisible.

public record RevisionWithEntity<T> (T data, Integer rev, RevisionType type,
                                     Instant at, Set<String> changes) {
    public RevisionWithEntity(T data,
                              DefaultRevisionEntity revision,
                              RevisionType type,
                              Set<String> changes) {
        this(data, revision.getId(), type,
                revision.getRevisionDate().toInstant(), changes);
    }

    public RevisionWithEntity(Object[] line) {
        this((T) line[0], (DefaultRevisionEntity) line[1], (RevisionType) line[2],
                line.length > 3 ? (Set<String>) line[3] : Set.of());
    }
}

Évidemment, il n’y a pas de magie, on a toujours autant de transtypage. Mais avec ce record, c’est encapsulé dans le constructeur. Il ne reste plus qu’à ajouter ça après l’appel de l’API de query, et d’enpacqueter ça dans une méthode publique.

public <E> List<RevisionWithEntity<E>> findHistoryById(Class<E> entityClass, Object id) {
    AuditQuery auditQuery = AuditReaderFactory.get(entityManager)
                .createQuery()
                .forRevisionsOfEntityWithChanges(entityClass, true)
                .add(AuditEntity.id().eq(id))
                .addOrder(AuditEntity.revisionNumber().desc());

    List<Object[]> list = auditQuery.getResultList();
    Stream<RevisionWithEntity<E>> revisionWithEntityStream = list.stream()
                .map(RevisionWithEntity::new);
    return revisionWithEntityStream.toList();
}

Cette petite amélioration permet de manipuler des variables typées.

<<component>>
HistoryRepository
- + findHistoryById(entityClass: Class<E>, id: Object): List<RevisionWithEntity<E>>

<<record>>
RevisionWithEntity<T>
- data: T
- rev: Integer
- type: RevisionType
- at: Instant
- changes: Set<String>

Service d’historique

Pour répondre au besoin, il faut travailler sur un service et des types plus spécifiques, qui permettent de stocker plus d’informations sur les différentes modifications.

<<component>>
HistoryService
- + getHistoryById(entityClass: Class<E>, id: K): List<HistoryDto<K>>

Le service retourne un DTO qui contient la liste des modifications. Celles-ci portent soit sur des champs (fieldChanges) soit sur des relations (toManyRelationChanges).

<<record>>
HistoryDto<K>
- revNumber: Integer
- id: K
- modificationInstant: Instant
- fieldChanges: Set<SimpleChange>
- toManyRelationChanges: Set<RelationChange>

Voyons maintenant comment construire ces ensembles de changements à partir de l’API d’Envers.

Champs et associations `@XxxToOne`

Pour répondre au besoin, il faut travailler sur des types plus spécifiques, qui permettent de stocker plus d’informations sur les différentes modifications.

Par exemple, pour chaque changement il nous faut les valeurs avant et après. C’est assez facile à faire pour des propriétés simples, c’est plus compliqué pour les relations de type @XxxToMany.

Pour les champs simples, on introduit un nouveau record SimpleChange. Il permet de gérer les champs simples (String, Long,…) mais aussi les associations @XxxToOne et assimilés.

public record SimpleChange(String propertyName, Object oldValue, Object newValue) {
}

Pour chaque révision, on construit une instance de SimpleChange par propriété modifiée. On y met le nom de la propriété modifiée, la valeur à la révision (newValue) et la valeur à la révision précédente (oldValue).

private <T extends AbstractEntity<?>> Set<SimpleChange> buildSimpleChanges(
        RevisionWithEntity<T> revision, RevisionWithEntity<T> previousRevision) {
    PropertyAccessor oldDataAccessor = buildPropertyAccessor(previousRevision);
    PropertyAccessor newDataAccessor = buildPropertyAccessor(revision);
    Set<String> changeNames = revision.changes().stream()
            .filter(not("class"::equals))
            .collect(Collectors.toSet());
    return changeNames.stream()
            .filter(change -> !isRelationChange(change, newDataAccessor))
            .map(change ->
                    new SimpleChange(
                            change,
                            buildPropertyValue(change, oldDataAccessor),
                            buildPropertyValue(change, newDataAccessor))
            )
            .collect(Collectors.toSet());
}

Pour les relations @XxxToOne, on aurait pu passer l’objet relié, et laisser le front-end se débrouiller. Le risque serait d’envoyer trop d’informations en JSON. On aurait aussi pu passer un simple toString(), mais ce n’est pas son rôle. On préfère passer un résumé (EntitySummary), avec l’identifiant et un contenu personnalisé avec une fonction historyDisplay().

private Object buildPropertyValue(String propertyName, PropertyAccessor data) {
    if (data == null) {
        return null;
    }
    Object value = data.getPropertyValue(propertyName);
    if (value instanceof AbstractEntity<?> entity) {
        return EntitySummary.fromEntity(entity);
    } else {
        return value;
    }
}

Ça c’est la partie simple, voyons maintenant les relations plus complexes.

<<component>>
HistoryService
- + getHistoryById(entityClass: Class<E>, id: K): List<HistoryDto<K>>
- - buildSimpleChanges(
  revision: RevisionWithEntity<T>,
  previousRevision: RevisionWithEntity<T>): List<SimpleChange>
- - buildFieldValue(data: PropertyAccessor, change: String): Object

<<record>>
SimpleChange
- fieldName: String
- oldValue: Object
- newValue: Object

Associations `@XxxToMany`

On considère que pour une relation @XxxToMany on a une collection et que les changements peuvent être de deux types: ajout ou suppression. Pour les relations ordonnées, on a un troisième type de changement: réordonnancement.

Comme pour les changements simples, on crée un record pour manipuler les informations.

public record RelationChange<K>(
        @JsonIgnore AbstractEntity<K> entity, String change, String type) {
    public EntitySummary<K> getElement() {
        return EntitySummary.fromEntity(entity);
    }
}

Ça commence de la même façon que pour les changements simple et la partie complexe est isolée dans la méthode buildToManyRelationChangesStream(…).

private <T extends AbstractEntity<?>> Set<RelationChange> buildToManyRelationChanges(
        RevisionWithEntity<T> revision, RevisionWithEntity<T> previousRevision) {
    PropertyAccessor oldDataAccessor = buildPropertyAccessor(previousRevision);
    PropertyAccessor newDataAccessor = buildPropertyAccessor(revision);
    return revision.changes().stream()
            .filter(change -> isRelationChange(change, newDataAccessor))
            .flatMap(change -> buildToManyRelationChangesStream(
                                        newDataAccessor, oldDataAccessor, change))
            .collect(Collectors.toSet());
}

private Stream<RelationChange> buildToManyRelationChangesStream(
            PropertyAccessor newDataAccessor, PropertyAccessor oldDataAccessor, String change) {
    TypeDescriptor changeDescriptor = newData.getPropertyTypeDescriptor(change);
    if (changeDescriptor == null) {
        return Stream.empty();
    }

    Collection<?> oldCollectionValue =
        (Collection<?>) buildPropertyValue(change, oldDataAccessor);
    Collection<?> newCollectionValue =
        (Collection<?>) buildPropertyValue(change, newDataAccessor);

    // 1st type of change: REMOVED
    List<?> removed = oldCollectionValue.stream()
            .filter(element -> !newCollectionValue.contains(element))
            .toList();
    Stream<RelationChange> removeChanges = removed.stream()
            .map(AbstractEntity.class::cast)
            .map(element -> buildRelationChange(element, change, REMOVED));

    // 2nd type of change: ADDED
    List<?> added = newCollectionValue.stream()
            .filter(element -> !oldCollectionValue.contains(element))
            .toList();
    Stream<RelationChange> addChanges = added.stream()
            .map(AbstractEntity.class::cast)
            .map(element -> buildRelationChange(element, change, ADDED));

    // 3nd type of change: REORDERED, only for ordered relations
    if (changeDescriptor.hasAnnotation(OrderBy.class)) {
        List<?> oldOrderedList = new ArrayList<>(oldCollectionValue);
        oldOrderedList.removeAll(removedEntities);
        List<?> newOrderedList = new ArrayList<>(newCollectionValue);
        newOrderedList.removeAll(addedEntities);

        Stream<RelationChange> reordered = IntStream.range(0, oldOrderedList.size())
                .filter(i -> !oldOrderedList.get(i).equals(newOrderedList.get(i)))
                .mapToObj(oldOrderedList::get)
                .map(AbstractEntity.class::cast)
                .map(element -> buildRelationChange(element, change, REORDERED));
        return Stream.concat(Stream.concat(removeChanges, addChanges), reordered);
    } else {
        return Stream.concat(removeChanges, addChanges);
    }
}

private RelationChange buildRelationChange(
            AbstractEntity<?> element, String change, RelationRevisionType type) {
    return new RelationChange(type, change, element);
}

<<component>>
HistoryService
- + getHistoryById(entityClass: Class<E>, id: K): List<HistoryDto>
- - buildSimpleChanges(
  revision: RevisionWithEntity<T>,
  previousRevision: RevisionWithEntity<T>): List<SimpleChange>
- - buildFieldValue(data: PropertyAccessor, change: String): Object
- - buildToManyRelationChanges(
  revision: RevisionWithEntity<T>,
  previousRevision: RevisionWithEntity<T>): List<RelationChange>
- - buildToManyRelationChangesStream(
  newData: PropertyAccessor,
  oldData: PropertyAccessor ,
  change: String): Stream<RelationChange>
- - buildRelationChange(
  element: AbstractEntity<?>,
  change: String,
  type: RelationRevisionType): RelationChange

<<record>>
RelationChange
- type: RelationRevisionType
- fieldName: String
- entity: AbstractEntity<?>

Assemblage

Voilà. Il ne reste plus qu’à assembler tout ça en implémentant la méthode publique getHistoryById(…) d'HistoryService.

Pour chaque révision trouvée par Envers, nous détectons si elle

public <E extends AbstractEntity<K>, K> List<HistoryDto> getHistoryById(
            Class<E> entityClass, K id) {
    List<RevisionWithEntity<T>> revisions = repository.findHistoryById(entityClass, id);
    return revisions.stream()
            .map((RevisionWithEntity<T> revision) -> {
                RevisionWithEntity<T> previousRevision = revisions.stream()
                        .filter(element -> element.rev() < revision.rev())
                        .findFirst()
                        .orElse(null);
                return new HistoryDto(
                        revision.rev(),
                        revision.type(),
                        revision.data().getId(),
                        revision.at(),
                        revision.author(),
                        buildSimpleChanges(revision, previousRevision),
                        buildToManyRelationChanges(revision, previousRevision));
            })
            .toList();
}

<<component>>
HistoryService
- + getHistoryById(entityClass: Class<E>, id: K): List<HistoryDto>
- - buildSimpleChanges(
  revision: RevisionWithEntity<T>,
  previousRevision: RevisionWithEntity<T>): List<SimpleChange>
- - buildFieldValue(data: PropertyAccessor, change: String): Object
- - buildToManyRelationChanges(
  revision: RevisionWithEntity<T>,
  previousRevision: RevisionWithEntity<T>): List<RelationChange>
- - buildToManyRelationChangesStream(
  newData: PropertyAccessor,
  oldData: PropertyAccessor ,
  change: String): Stream<RelationChange>
- - buildRelationChange(
  element: AbstractEntity<?>,
  change: String,
  type: RelationRevisionType): RelationChange

Endpoint

Pour finir, il reste à utiliser le service qu’on vient de concevoir dans des endpoints.

@RestController
@RequestMapping("/document")
public class DocumentController {
    ...

    @GetMapping("/{id}/history")
    public List<HistoryDto> getHistory(@PathVariable UUID id) {
        return historyService.getHistory(Document.class, id);
    }
}

Après avoir créé un document, puis fait quelques modifications, on obtient l’historique suivant:

~$ curl -sw "\n" http://localhost:8080/api/product/1/history | jq
[
  {
    "revNumber": 3,
    "id": 1,
    "type": "MOD",
    "at": "2024-09-09T21:24:49.375Z",
    "toManyRelationChanges": [
      {
        "change": "tags",
        "type": "REORDERED",
        "element": {
          "id": 3,
          "description": "Tag#3",
          "clazz": "info.jtips.spring.model.Tag"
        }
      },
      {
        "change": "tags",
        "type": "REORDERED",
        "element": {
          "id": 5,
          "description": "Tag#5",
          "clazz": "info.jtips.spring.model.Tag"
        }
      }
    ]
  },
  {
    "revNumber": 2,
    "id": 1,
    "type": "MOD",
    "at": "2024-09-09T21:24:49.364Z",
    "fieldChanges": [
      {
        "fieldName": "title",
        "oldValue": "Product#1",
        "newValue": "Product#1bis"
      },
      {
        "fieldName": "category",
        "oldValue": {
          "id": 1,
          "description": "Category#1",
          "clazz": "info.jtips.spring.model.Category"
        },
        "newValue": {
          "id": 2,
          "description": "Category#2",
          "clazz": "info.jtips.spring.model.Category"
        }
      }
    ],
    "toManyRelationChanges": [
      {
        "change": "tags",
        "type": "REMOVED",
        "element": {
          "id": 2,
          "description": "Tag#2",
          "clazz": "info.jtips.spring.model.Tag"
        }
      },
      {
        "change": "tags",
        "type": "ADDED",
        "element": {
          "id": 5,
          "description": "Tag#5",
          "clazz": "info.jtips.spring.model.Tag"
        }
      }
    ]
  },
  {
    "revNumber": 1,
    "id": 1,
    "type": "ADD",
    "at": "2024-09-09T21:24:49.321Z"
  }
]

Conclusion

Pour être tout à fait honnête, j’ai simplifié quelques passages pour rendre le billet plus lisible. Par exemple, on a dû gérer quelques cas particuliers pour les relations, et on a dû gérer des erreurs en particulier pour les relations avec des entités revisées de façon conditionnelle. Et dans notre application on fait du soft delete ainsi que de la pagination, que j’ai exclus ici.

Par ailleurs, on n’utilise qu’une partie des possibilités des relations de JPA et Hibernate. Il y a certainement des ajustements à prévoir.

Enfin, la solution utilise une structure d’entité qui n’est pas universelle, avec l’héritage de AbstractEntity. C’est suffisant pour notre projet, mais peut-être pas dans un autre contexte.

AbstractEntity<K>
- id: K
- historyDisplay(): Supplier<String>

Le code utilisé dans les exemples est consultable et exécutable sur le compte GitLab de JTips.

Retour d’expérience, migration à Spring Boot 3

2023-04-06T00:00:00+00:00

Ces dernières semaines, j’ai dû faire une migration de Spring Boot 2 à Spring Boot 3. Comme dans Spring Boot il y a toute une suite de frameworks et librairies, avec en particulier Spring Framework, Spring Security, Hibernate, ça fait pas mal de galères potientielles.

J’ai lu quelques articles et billets sur le sujet, en particulier le guide de migration du projet Spring. J’en ai conclu que ça n’allait pas être très compliqué, avec surtout un gros rechercher/remplacer de javax.* pour jakarta.*. Evidemment ça ne s’est pas passé aussi simplement que prévu, c’est ce que je vais raconter ici.

L’application est construite sur des bases classiques. Elle implémente un API Web, avec du contenu JSON. Elle est organisée en couches avec des controllers, des services et des repositories. Pour ces derniers, on utilise Spring Data JPA, avec Hibernate et une base de données PostgreSQL. Bref, une application comme il en existe plein.

Tâches préalables

Comme ça avait été annoncé dès 2021, nous savions que nous devions utiliser un JDK 17 pour pouvoir utiliser Spring Boot 3. Bien avant la migration, on avait passé notre code du JDK 11 au JDK 17.

Il y a eu un peu plus de surprise avec Swagger. On utilisait SpringFox pour générer la documentation de l’API à afficher dans SwaggerUI. Or SpringFox n’a pas été mis à jour pour être compatible avec Spring Boot 3. Je l’ai donc abandonné pour Springdoc. Au passage, on utilisait des annotation Swagger v2 qu’il a fallut remplacer par des annotations OpenAPI v3. J’en ai profité pour poser mes notes de configuration de Springdoc sur JTips.

Le passage de Hibernate 5 à Hibernate 6 implique pas mal de changements, dont l’abandon du support direct d'Ehcache. Pour continuer de l’utiliser, il faut utiliser JCache (ou JSR-101) et faire en sorte qu’Ehcache en soit le provider.

L’authentification se fait avec OIDC sur un serveur d’autorisation intégré à l’application, basé sur Spring Authorization Server. Au démarrage du projet, cette librairie était en version 0.3. Forcément, comme on n’était pas en version finale, on pouvait craindre à pas mal de changements. En l’occurence, les changements se sont fait sur la version 0.4, compatible avec Spring Boot 2 ; le passage à la version 1.0, compatible avec Spring Boot 3, est beaucoup moins important.

En plus de quelques changements de packages, il a fallu modifier toutes les références à la classe ProviderContext qui a changé de nom pour AuthorizationServerContext. Par ailleurs, le support d’OIDC n’est plus activé par défaut, il faut le déclarer explicitement.

    authorizationServerConfigurer.oidc(oidcConfigurer -> {});

Avec tout ça, on était prêt à passer à Spring Boot 3.

Tâches prévues

Grâce à lecture du guide de migration et de quelques autres billets, on connaissait un certain nombre de tâches.

Il y a pas mal de petits changements sur Spring Security, au point où il a son guide de migration dédié.

WebSecurityConfigurerAdapter n’existe plus.
Quelques méthodes de HttpSecurity ont changé.
- securityMatcher(…) remplace requestMatcher(…)
- authorizeHttpRequests(…) remplace authorizeRequests(…)
- requestMatchers(…) remplace antMatchers(…)

Pour Spring integration, les changements se limitent à une plus grande utilisation de Instant à la place de Date.

Dans la classe Trigger, nextExecutionTime() remplacé par nextExecution().
Dans la classe TriggerContext, lastActualExecutionTime() est déprécié en faveur de lastActualExecution().

Le gros morceau semblait être le passage de Java EE à Jakarta EE, avec plusieurs packages qui sont renommés de javax.zzz à jakarta.zzz.

Servlet: javax.servlet ⇒ jakarta.servlet
JPA: javax.persistence ⇒ jakarta.persistence
Bean Validation: javax.validation ⇒ jakarta.validation
Annotations: javax.annotation ⇒ jakarta.annotation
Mail: javax.mail ⇒ jakarta.mail

Finalement le changement de packages est rapide, mais il faut aussi mettre à jour les librairies qui dépendent de Java EE.

com.fasterxml.jackson.datatype:jackson-datatype-hibernate5 ⇒ com.fasterxml.jackson.datatype:jackson-datatype-hibernate5-jakarta.
com.vladmihalcea:hibernate-types-55 ⇒ io.hypersistence:hypersistence-utils-hibernate-62

Tâches pas prévues

Peut-être que j’ai manqué de concentration en lisant le guide de migration à Hibernate 6, mais je ne pensais pas que le changement sur la gestion des types aurait autant d’impact. On avait anticipé les gros changemenents dans la classe UserType en remplaçant nos types personnalisés par ceux de la librairie Hypersistence Utils de Vlad Mihalcea.

Ensuite, il a fallu retoucher pas mal d’annotations et remplacer du texte par des classes. C’est plus typé, c’est mieux, plus propre. Avant, pour associer une propriété à une colonne de type jsonb, il fallait déclarer le type au niveau de la classe, puis l’utiliser par son nom au niveau de la propriété.

@TypeDef(name = "jsonb", typeClass = JsonBinaryType.class)
public class Product {
  @Type(type = "jsonb")
  private String detailAsJson;
  ...
}

Dans Hibernate 6, l’annotation @TypeDef a disparu et l’annotation @Type fait directement référence à la classe de description du type jsonb.

public class Product {
  @Type(JsonBinaryType.class)
  private String detailAsJson;
  ...
}

Pour le type UUID, la gestion a aussi pas mal changé, pour plus de simplicité. Avec Hibernate 6, on retire les annotations @Type(type = "org.hibernate.type.UUIDCharType"). A la place on choisit la façon d’associer les propriétés UUID via la propriété preferred_uuid_jdbc_type d’Hibernate (CHAR, VARCHAR, UUID).

spring.jpa.properties.hibernate.type.preferred_uuid_jdbc_type=VARCHAR

Au passage, comme on utilise beaucoup les filtres d’Hibernate et qu’il y a un bug gênant dans la version 6.0, on est directement passé à la version 6.2.

Enfin, il y a eu un travail important sur l’intégration de la RFC-7807 (Problem Details for HTTP APIs). On utilisait Zalando Problem qui n’a pas été migrée et qui ne le sera probablement jamais puisque qu’elle est devenue inutile. En effet, Spring Framework 6 a intégré le support de RFC-7807. Il a donc fallu jeter tout le travail qui avait été réalisé et le réimplanté dans la nouvelle version.

Après tout ça, l’application fonctionnait, mais pas les tests d’intégration. On utilise RestTemplate avec une configuration adaptée aux tests, pour les redirection et la gestion relachée des cookies. Le passage de Apache HttpClient 4 à Apache HttpComponents 5 est documenté, mais j’ai passé plus de temps que prévu sur le sujet. Pour la gestion des cookies, la configuration a juste un peu changé.

  // Apache HttpClient 4
  private static HttpClient buildHttpClient() {
    RequestConfig requestConfig = RequestConfig.custom()
            .setCookieSpec(CookieSpecs.STANDARD_STRICT)
            .build();
    return HttpClientBuilder.create()
            .setDefaultRequestConfig(requestConfig)
            .setRedirectStrategy(new LaxRedirectStrategy())
            .build();
  }

  // Apache HttpComponents 5
  private static HttpClient buildHttpClient() {
    RequestConfig requestConfig = RequestConfig.custom()
            .setCookieSpec(StandardCookieSpec.RELAXED)
            .build();
    return HttpClientBuilder.create()
            .setDefaultRequestConfig(requestConfig)
            .setRedirectStrategy(new DefaultRedirectStrategy())
            .build();
  }

Malheureusement, ça n’a pas suffit pour la gestion des redirections de requêtes POST vers GET. Dans la nouvelle version, la classe RedirectExec ne joint jamais les cookies à la requête GET. La seule solution pour y arriver a été de faire ma propre classe CustomRedirectExec identique à l’original mais avec une récupération des headers en plus.

    ...
    currentRequest = redirectBuilder.build();
    // Ça c'est l'ajout perso
    currentRequest.setHeaders(scope.originalRequest.getHeaders());
    EntityUtils.consume(response.getEntity());
    response.close();

Enfin, il a fallu faire quelques petits ajustements dans les tests d’intégration.

Les URLs sont gérés avec plus de rigueur pour le '/' de fin.
Les content types demandent aussi plus de rigueur.

Conclusion

J’avais planifié une petite semaine pour cette migration. Au final, elle m’a pris plus du double. Pour être plus précis, j’ai passé environs 80 heures pour identifier, comprendre et résoudre les problèmes que j’ai présenté ici, plus quelques pétouilles qui n’ont pas d’intérêt ici.

Tests d’intégration, comment vérifier que le ménage a été fait ?

2022-07-02T00:00:00+00:00

Encore un billet sur les tests, et plus précisément sur les tests d’intégration en Java. Dans ma mission actuelle, il y a beaucoup de tests d’intégration, trop à mon goût. Et ce sont généralement des tests avec une intégration complète : le test envoie une requête HTTP à laquelle le backend testé renvoie une réponse construite avec des données issue d’une base de données de test.

Pour les faire fonctionner de façon reproductible, aussi bien en local qu’en intégration continue, ça demande quelques contorsions. J’ai donc cherché des idées pour les améliorer.

Aujourd’hui, je vais vous expliquer ce qu’on a fait pour résoudre le problème du ménage dans les données.

Le problème

Lorsqu’on développe un test d’intégration, on doit laisser le système dans l’état dans lequel on l’a trouvé en arrivant.

Ça concerne en particulier les données en base. On initialise des données pour chaque test, le test lui-même peut ajouter ou modifier des données. Pour que le test suivant se déroule correctement, il faut faire le ménage après chaque test ou chaque classe de test.

metricsRepository.deleteAll();
deviceRepository.deleteAll();

Le problème avec ces tests d’intégration, c’est qu’on ne cherche pas à isoler un composant particulier. De ce fait, certaines actions peuvent impacter plusieurs tables. A plusieurs reprises, l’auteur du test a oublié des données, parce qu’il n’avait pas conscience qu’elle avaient pu être créées.

Nous avons décidé de mettre en place un dispositif d’aide au développeur pour l’alerter s’il oublie des données.

Extension JUnit

Nous utilisons JUnit 5 qui a un système d’extension très puissant. Par rapport à JUnit 4, il a été complètement remis à plat et remplace à la fois les runners et les rules.

Ce qui va nous intéressé, c’est la possibilité de s’insérer dans le cycle de vie des tests. Ça marche un peu à la façon des méthodes annotées @BeforeAll, @BeforeEach, @AfterEach ou @AfterAll, mais dans une classe indépendante et réutilisable.

Pour vérifier l’état de la base de données, on développe une classe qui implémente AfterAllCallback. Ça devient une sorte de méthode @AfterAll pour chaque classe de test qui déclare l’extension.

public class CheckEntitiesExtension implements AfterAllCallback {

  @Override
  public void afterAll(ExtensionContext extensionContext) {
    // ...
  }

}

L’extension est activée pour chaque classe de test qui la déclare dans @ExtendWith. Une classe de test peut déclarer plusieurs exensions, ce qui nous arrange puisqu’on veut ajouter notre vérification à des tests d’intégration qui ont déjà l’extension SpringExtension.

@ExtendWith({SpringExtension.class, CheckEntitiesExtension.class})
public class DeviceApiIT {
  // ...
}

Intégration avec Spring et JPA

Notre architecture se base sur Spring Boot, avec Spring Data JPA. La plupart des accès à la base de données se font avec des interfaces repository, à base de méthodes abstraites et de conventions de nommage. Mais Spring Boot a des beans qui nous permettent de faire du pur JPA.

La première étape est de récupérer le contexte d’application qui a été démarré par l’extension Spring. On l’utilise pour récupérer quelques beans comme l'`EntityManager` et le TransactionManager.

  @Override
  public void afterAll(ExtensionContext extensionContext) {
    ApplicationContext applicationContext
        = SpringExtension.getApplicationContext(extensionContext);

    EntityManager entityManager = applicationContext.getBean(EntityManager.class);
    PlatformTransactionManager transactionManager =
        applicationContext.getBean(PlatformTransactionManager.class);

    //...
  }

A partir de là, on peut se concentrer sur les données avec JPA. On récupère la liste des entités via les méta-données de l'entity manager. Pour chaque entité, on compte le nombre d’occurences en base et si ce nombre est positif c’est qu’il reste des données dans le table. Dans ce cas, on fait échouer le test.

  @Override
  public void afterAll(ExtensionContext extensionContext) {
    //...
    List<String> found =
        entityManager.getMetamodel()
            .getEntities()
            .stream()
            .filter(entityType -> count(entityManager, entityType) > 0)
            .map(EntityType::getName)
            .collect(Collectors.toList());

    if (!found.isEmpty()) {
      fail("Data found : " + String.join(", ", found));
    }
  }

Pour compter le nombre d’occurences en base de données, j’ai utilisé l’API Criteria de JPA. Le code est générique sans grand effort.

  private static Long count(EntityManager entityManager, EntityType<?> entityType) {
    CriteriaBuilder criteriaBuilder = entityManager.getCriteriaBuilder();
    CriteriaQuery<Long> query = criteriaBuilder.createQuery(Long.class);
    query.select(criteriaBuilder.count(query.from(entityType)));
    return entityManager.createQuery(query).getSingleResult();
  }

OK, c’est pas un bout de code très élégant, mais caché dans une méthode, ça passe.

Améliorations

Vous vous demandez peut-être pourquoi je compte le nombre d’occurences et pourquoi je ne me contente pas d’un exists. C’est parce que je veux afficher cette information dans le fail.

De plus, certaines données sont initialisées au démarrage de Spring. Il ne faut pas faire le ménage dans ces données et les exclure de la vérification.

  private final Set<String> excludedEntityNames =
      Set.of(
          UserDbEntity.class.getSimpleName(),
          TermsDbEntity.class.getSimpleName(),
          FirmwareDbEntity.class.getSimpleName());

  @Override
  public void afterAll(ExtensionContext extensionContext) {
    // ...

    List<String> found =
        entityManager.getMetamodel()
            .getEntities()
            .stream()
            .filter(entityType -> !excludedEntityNames.contains(entityType.getName()))
    // ...

On ne se contente pas de vérifier que le ménage a été fait, mais on fait la suppression des données dans l’extension. Le but n’est pas de mettre en place un ménage automatique. On reste sur l’objectif d’alerter le développeur. C’est lui qui est responsable de son test, de la préparation jusqu’à la remise en état. Non, on fait ça pour éviter qu’un test mal nettoyé ne fasse resortir tous les autres tests en échec.

Dans la pratique, on a directement intégré ces améliorations, mais je n’ai présenté qu’un code simplifié.

Synthèse

La première préoccupation lorsqu’on intégre ce genre de vérification, avec beaucoup d’accès à la base de données, c’est le surcoût en temps de build. Sur mon poste de travail, il est de sept dizièmes de seconde, pour un build complet de trois minutes. En environnement d’intégration (CI), il est d’une seconde et demi, pour un build complet de dix minutes. Autant dire que c’est négligeable.

Dans notre projet toutes les classes de tests d’intégration héritent d’une classe abstrait AbstractIT. Il suffit d’ajouter l’extension à cette classe abstraite pour que tous les tests d’intégration en profitent.

L’effet immédiat, ça a été de casser le build. C’est dû à plusieurs tests qui ne faisaient pas bien leur ménage. Ça tombe bien, c’est justement ce qu’on cherche à identifier. On a dû leur ajouter des appels à repository.deleteAll() dans des méthodes @AfterAll.

Une fois ce ménage fait, que le build passe, l’extension commence à remplir son objectif principal : quand un développeur oublie des données en fin de test, son test ne passe plus, ni en local ni en CI. Il est obligé de faire son ménage, et s’en rend compte directement dans l’IDE.

java.lang.AssertionError: Data found : DeviceDbEntity(1)

Avec cette simple extension, c’est la fin du casse-tête sur les builds qui ne passent pas à l’appel de mvn verify alors qu’ils passent seuls. On ne s’arrache plus les cheveux parce qu’un nouveau test d’intégration est en échec à cause du test passé avant lui qui avait laissé des données en trop.

Par contre, il reste plein de problèmes liés aux traitements asynchrones, et ça j’en parlerai dans un prochain billet.

Comment vérifier l’envoi d’e-mails en test d’intégration ?

2022-05-04T00:00:00+00:00

En avril, je traitais le sujet de la date dans les tests. Je continue sur ma lancée avec les tests, mais cette fois-ci il s’agit de tests d’intégration et de l’envoi d’e-mails.

Lorsqu’une application envoie des e-mails, ses tests d’intégration doivent d’une part avoir accès à un serveur SMTP, mais ils doivent aussi pouvoir valider que les messages envoyés sont conformes aux attentes. Nous allons aborder ces deux aspects.

Docker, évidemment

Docker va nous apporter plus qu’un simple accès, il permet aussi de l’isolation et de la reproductibilité des tests. En utilisant Testcontainers, on peut démarrer des conteneurs directement depuis les tests, en récupérer la configuration pour l’utiliser pour paramétrer la connexion. Je ne vais pas développer ce sujet ici, j’y ai déjà consacré une page sur JTips, globalement pour les tests d’intégration d’un part et plus spécifiquement pour les tests avec Spring d’autre part.

On va se concentrer sur l’utilisation d’un conteneur basé sur MailHog. Cette application se comporte comme un serveur SMTP et stocke les messages pour les restituer via une page Web.

Dans l’exemple ci-dessous, je démarre un serveur MailHog dans un environnement Spring Boot.

public class TestContextInitializer
    implements ApplicationContextInitializer<ConfigurableApplicationContext> {

  @Override
  public void initialize(ConfigurableApplicationContext context) {
    // Démarrage du conteneur
    GenericContainer smtp = new GenericContainer<>("mailhog/mailhog")
        .withExposedPorts(1025, 8025);
    smtp.start();

    // Injection des caractéristiques dans les propriétés de Spring Boot
    TestPropertyValues
        .of("spring.mail.host=" + smtp.getContainerIpAddress())
        .of("spring.mail.port=" + smtp.getMappedPort(1025))
        .of("spring.mail.http-port=" + smtp.getMappedPort(8025))
        .applyTo(context);
  }

}

Maintenant qu’on a un serveur SMTP et que nos e-mails y sont envoyés, voyons comment on peut vérifier qu’on lui envoie les bons messages.

On a vu en préambule que MailHog donnait accès aux messages via une page Web. Il offre aussi une API HTTP pour y accéder par programme, dont les pincipaux endpoints :

Lire tous les messages : GET /api/v2/messages
Supprimer tous les messages : DELETE /api/v1/messages
Lire un message : GET /api/v1/messages/{id}
Supprimer un message : DELETE /api/v1/messages/{id}

Cette API permet de vérifier le nombre de messages envoyés avec succès et le contenu des messages envoyés. Le plus pratique est probablement d’encapsuler l’API dans une classe MailHogClient.

  @Test
  void action_should_send_message() {
    // GIVeN
    mailHogClient.deleteAllMessages();

    // WHeN
    service.doAction();

    // THeN
    Message message = mailHogClient.findLatestMessages();
    assertThat(message).isNotNull();
    assertThat(message.getContentType()).startsWith("text/html");
    assertThat(message.getSubject()).startsWith("Hello World");
  }

Au final, ça fait beaucoup de tuyauterie pour valider qu’on a envoyé les bons messages. Il faut du Docker avec Testcontainers, et du code pour les messages par l’API.

Mock

Plutôt que de déployer tout ça, on pourrait opter pour une solution plus simple en remplaçant le composant d’envoi d’e-mails par un mock. Dans Spring, ce composant est un bean de type MailSender ou JavaMailSender.

@Configuration
public class IntegrationTestConfiguration {

  @Bean
  public JavaMailSender mockJavaMailSender() {
    return mock(JavaMailSender.class);
  }

}

Avec Spring Boot, il n’y a pas de conflit puisque le MailSender classique n’est instancié que s’il n’y a pas d’instance par ailleurs. Sinon, on peut toujours ajouter @Primary pour résoudre le conflit.

Ensuite, on injecte le bean dans le test et on l’utilise comme un mock normal. Sauf qu’il faut le réinitialiser.

public class SomeIT {

  @Autowired JavaMailSender mailSender

  @BeforeEach
  public void before() {
    //reset mock
    reset(mailSender);
  }

  @Test
  public void action_should_send_email() {
    // GIVeN
    //...

    // WHeN
    service.action();

    // THeN
    verify(mailSender, times(1)).send(any(MimeMessage));
    verify(mailSender, never()) .send(any(MimeMessage[]));
    verify(mailSender, never()) .send(any(MimeMessagePreparator));
    verify(mailSender, never()) .send(any(MimeMessagePreparator[]));
  }

}

Cette solution impose moins de tuyauterie, mais resteint le périmètre de l’intégration. On ne vérifie pas que l’envoi de messages se passe bien, mais uniquement qu’on a essayé.

Les deux mon capitaine

Il est possible de combiner les avantages des deux solutions. Pour ça, on va concerver un vrai MailSender et lui adjoindre une variante décorée (spy) par Mockito.

Pour avoir les deux beans, c’est assez facile avec Spring Framework sans Boot. On crée une classe de configuration dédiée aux tests, avec une méthode de fabrique MailSender espionné, dans laquelle on injecte le bean normal.

@Configuration
@EnableConfigurationProperties(MailProperties.class)
public class MainConfiguration {
  @Bean
  public JavaMailSender mailSender(MailProperties properties) {
    JavaMailSender mailSender = new JavaMailSender();
    // ...
    return mailSender;
  }
}

@Configuration
public class IntegrationTestConfiguration {
  @Bean
  @Primary
  public JavaMailSender spyMailSender(
        @Qualifier("mailSender") JavaMailSender mailSender) {
    return spy(mailSender);
  }
}

Avec Spring Boot, c’est un peu plus complexe. Comme on l’a vu dans le chapitre précédent, lorsqu’on déclare un nouveau bean de type MailSender pour les tests, Boot ne produit plus son MailSender normal. C’était bien partique avec le mock, puisqu’on ne voulait plus du bean normal. Avec le spy, ça nous oblige à dupliquer du code existant pour instancier explicitement le JavaMailSender à espionner.

@Configuration
@EnableConfigurationProperties(MailProperties.class)
public class IntegrationTestConfiguration {

  @Bean
  public JavaMailSender spyJavaMailSender(MailProperties properties) {
    return spy(buildMailSender(properties, sender));
  }

  private JavaMailSender buildMailSender(MailProperties properties) {
    JavaMailSenderImpl sender = new JavaMailSenderImpl();

    sender.setHost(properties.getHost());
    if (properties.getPort() != null) {
      sender.setPort(properties.getPort());
    }
    sender.setUsername(properties.getUsername());
    sender.setPassword(properties.getPassword());
    sender.setProtocol(properties.getProtocol());
    if (properties.getDefaultEncoding() != null) {
      sender.setDefaultEncoding(properties.getDefaultEncoding().name());
    }
    if (!properties.getProperties().isEmpty()) {
      sender.setJavaMailProperties(asProperties(properties.getProperties()));
    }

    return sender;
  }

  private Properties asProperties(Map<String, String> source) {
    Properties properties = new Properties();
    properties.putAll(source);
    return properties;
  }
}

Avec cette configuration, on valide que les messages partent bien en SMTP et on peut vérifier le contenu de ce qu’on envoie.

A vous de choisir le niveau de tuyauterie et de vérification vous souhaitez implémenter. En tout, il n’y a aucune raison de ne pas vérifier que l’envoi de messages est conforme.

On me souffle dans l’oreillette que j’aurais pu simplifier mon code en déclarant un mock local avec l’annotation de Spring Boot @MockBean, ou un _spy local avec @SpyBean.

Une histoire de temps et de tests

2022-04-01T00:00:00+00:00

Le temps, c’est compliqué, ça change tout le temps. Et je ne parle pas de météo, mais bien du temps qui passe. Et c’est justement parce qu’il passe que ça change.

Bon, je vais m’arrêter là avec les pensées profondes. Je n’ai pas prévu de marquer l’histoire de la philosophie avec ce billet. Ce qui m’intéresse ici, c’est de pouvoir tester des méthodes qui utilisent des objets temporels, et plus précisément des objets du package récent java.time : Instant.now(), LocalDateTime.now(), ZonedDateTime.now(),…

Partons sur ce petit exemple, dans lequel on choisit une activité distincte en fonction de l’heure de la journée.

public class ActivityService {

  private final Action action;

  public ActivityService(Action action) {
    this.action = action;
  }

  public void chooseActivity() {
    if (LocalDateTime.now().get(ChronoField.AMPM_OF_DAY) == 0) {
      action.doSleep();
    } else {
      action.doPlay();
    }
  }

}

En utilisant le code tel quel, action.doSleep() est appelé si le test est exécuté le matin et action.doPlay() si le code est appelé l’après-midi. Voyons comment adapter le code pour qu’on puisse développer tester de façon reproductible.

On a toujours fait comme ça

Commençons par la technique la plus classique, que j’utilise et vois utilisée depuis une bonne vingtaine d’années. Elle consiste à déléguer la création des dates à un builder, qu’on injecte dans notre classe.

public class ActivityService {

  private final Action action;
  private final DateBuilder dateBuilder;

  public ActivityService(Action action, DateBuilder dateBuilder) {
    this.action = action;
    this.dateBuilder = dateBuilder;
  }

  public void chooseActivity() {
    if (dateBuilder.currentLocalDateTime().get(ChronoField.AMPM_OF_DAY) == 0) {
      action.doSleep();
    } else {
      action.doPlay();
    }
  }

}

Bâtisseur de dates

Avec cette façon de procéder, on n’appelle jamais Instant.now() directement, ni aucune méthode autre méthode Xxx.now(). Le builder est la seule classe ayant cette responsabilité.

public class DateBuilder {

  public Instant currentInstant() {
    return Instant.now();
  }

  public LocalDateTime currentLocalDateTime() {
    return LocalDateTime.now();
  }

  //...
}

Pour supporter toutes les méthodes Xxx.now(), on doit implémenter une dizaine de méthodes dans DateBuilder. A ça il faut ajouter les variantes qui prennent un paramètre de type ZoneId (LocalDateTime.now(ZoneId zone), ZonedDateTime.now(ZoneId zone),…), ce qui nous fait monter à une petite vingtaine de méthodes (19 pour être précis).

Moquons le maçon

Pour tester unitairement ActivityService, on va créer des mocks des dépendances, y compris pour DateBuilder. De cette façon, à chaque appel, l’objet produira la date et l’heure qu’on a choisies dans la préparation du test. Et donc le test est parfaitement indépendant de l’heure d’exécution et devient reproductible.

  @Test
  void chooseActivity_should_play_in_the_afternoon() {
    // GIVeN
    var action = mock(Action.class);
    var dateBuilder = mock(DateBuilder.class);
    when(dateBuilder.currentLocalDateTime())
        .thenReturn(LocalDateTime.parse("1970-01-01T21:00"));

    var activityService = new ActivityService(action, dateBuilder);

    // WHeN
    activityService.chooseActivity();

    // THeN
    verify(action, never()).doSleep();
    verify(action, times(1)).doPlay();
  }

Remettons l’horloge au centre du village

source: Bibliothèque municipale de Lyon

Depuis le JDK 8, il existe une autre solution, suggérée directement dans la javadoc du JDK. Dans les explications sur la classe abstraite Clock, on trouve ce passage :

All key date-time classes also have a now() factory method that uses the system clock in the default time zone. The primary purpose of this abstraction is to allow alternate clocks to be plugged in as and when required. Applications use an object to obtain the current time rather than a static method. This can simplify testing.

— java.time.Clock
javadoc

Cette classe permettrait donc de simplifier les tests. C’est exactement ce qu’on recherche, on va donc s’y intéresser.

Rock around the `Clock`

Avant de voir comment elle peut nous simplifier les tests, voyons ce qu’elle fait. Et pour ça, revenons à la javadoc.

A clock providing access to the current instant, date and time using a time-zone.

— java.time.Clock
javadoc

Clock
- instant(): Instant
- getZone(): ZoneId

Son rôle, c’est de fournir l’instant courant, et c’est à peu près tout.

L’implémentation par défaut fait ça avec les informations du système, via la méthode native System.currentTimeMillis(). C’est celle qui est utilisée lorsqu’on appelle une méthode Xxx.now() sans paramètre. Toutes ces méthodes ont une variante avec un paramètre Clock permettant de s’appuyer sur un autre référenciel.

Instant
- now(): Instant
- now(Clock clock): Instant

LocalDateTime
- now(): LocalDateTime
- now(Clock clock): LocalDateTime

ZonedDateTime
- now(): ZonedDateTime
- now(Clock clock): ZonedDateTime

Donnons du temps au temps

Maintenant qu’on a posé ces bases, on se rend compte qu’on peut très bien injecter une instance de Clock plutôt qu’un DateBuilder. Pour en profiter, il faut s’obliger à utiliser les méthodes Xxx.now(…) qui prennent un paramètre de type Clock, au détriment des variantes sans paramètre.

public class ActivityService {

  private final Action action;
  private final Clock clock;

  public ActivityService(Action action, Clock clock) {
    this.action = action;
    this.clock = clock;
  }

  public void chooseActivity() {
    if (LocalDateTime.now(clock).get(ChronoField.AMPM_OF_DAY) == 0) {
      action.doSleep();
    } else {
      action.doPlay();
    }
  }

}

On abandonne l’idée d’un builder construit par nos soins et on n’utilise que des classes de l’API standard.

Un jour j’irai à New-York avec toi

Plus haut, j’avais dit que les méthodes Xxx.now() avaient presque toutes une variante avec une instance de ZoneId en paramètre, pour positionner les objets temporels dans un fuseau horaire. Ça ne concerne pas Instant, mais LocalDateTime, ZonedDateTime,….

Maintenant qu’on a abandonné les méthodes sans paramètre au profit de la variante avec un paramètre de type Clock, voyons ce que ça donne avec les fuseaux horaires.

Il n’y a pas de variante avec deux paramètres Xxx.now(clock, zoneId) comme on pourrait s’y attendre. C’est l’objet Clock qui porte les informations de fuseau.

Clock
- system(ZoneId zone): Clock
- getZone(): ZoneId
- withZone(ZoneId zone): Clock

Grâce à la méthode withZone(…) appelée sur l’objet injecté, on crée une copie positionnée sur le fuseau horaire de notre choix.

public class ActivityService {

  private final Action action;
  private final Clock clock;

  public ActivityService(Action action, Clock clock) {
    this.action = action;
    this.clock = clock;
  }

  public void chooseActivity(ZoneId zoneId) {
    if (LocalDateTime.now(clock.withZone(zoneId)).get(ChronoField.AMPM_OF_DAY) == 0) {
      action.doSleep();
    } else {
      action.doPlay();
    }
  }

}

Ceci soulève une autre question. La question originelle. Comment l’instance injectée doit-elle être créée ? Une instance de Clock pouvant être positionnée dans un fuseau horaire, comment faut-il instancier l’horloge de référence ?

Clock
- systemUTC(): Clock
- systemDefaultZone(): Clock
- system(ZoneId zone): Clock

Comme on parle d’horloge de référence, on va la positionner sur le fuseau horaire de référence, le fuseau UTC. On va utiliser la méthode statique systemUTC(), qui est d’ailleurs utilisée par Xxx.now() sans paramètre.

Ni clou, ni vis

Dans la première solution, on pouvait tester la classe de service grâce à des objets mock. On pourrait aussi faire un mock de Clock afin de figer la date et l’heure qu’il fournit.

    Clock clock = mock(Clock.class);
    when(clock.getZone()).thenReturn(ZoneOffset.UTC);
    when(clock.instant()).thenReturn(Instant.EPOCH.plus(21, HOURS));

Ça fonctionne, mais avec Clock, il n’y plus besoin de ça. En effet, le JDK fournit directement une implémentation adaptée aux tests. Elle se présente sous la forme d’une horloge fixe, qui retourne toujours la même heure.

    Clock clock = Clock.fixed(Instant.EPOCH.plus(21, HOURS), ZoneOffset.UTC);

Avec cette horloge, tous les instants créés seront à la même heure.

    Instant instant1 = Instant.now(clock);
    logger.info(instant1)
    // 1970-01-01T21:00:00Z
    ...
    // Later
    Instant instant2 = Instant.now(clock);
    logger.info(instant2)
    // 1970-01-01T21:00:00Z

Voici ce que devient le test unitaire avec une telle horloge.

  @Test
  void chooseActivity_should_play_in_the_afternoon() {
    // GIVeN
    var action = mock(Action.class);
    var clock = Clock.fixed(Instant.EPOCH.plus(21, HOURS), ZoneOffset.UTC);;

    var activityService = new ActivityService(action, clock);

    // WHeN
    activityService.chooseActivity();

    // THeN
    verify(action, never()).doSleep();
    verify(action, times(1)).doPlay();
  }

Au vent en emporte le temps

A partir du moment où on utilise des objets temporels du paquetage java.time, une classe DateBuilder ne sert à rien. C’est même une abstraction inutile. En injectant un objet (ou bean) de type Clock, on arrive à avoir un code tout aussi facile à tester, en restant sur l’API standard.

Par contre, si on utilise encore les anciennes API avec java.util.Date et java.util.Calendar, on n’a pas le choix, il faut passer par un builder.

Et comme j’ai commencé par de la philosophie de haut niveau, je vais conclure avec de la poésie de haut niveau.

Pour le bonheur
De nos deux cœurs
Arrête le temps et les heures
Je t’en supplie
A l’infini
Retiens la nuit

Quand est-ce qu’on change d’heure ?

2022-03-01T00:00:00+00:00

C’est assez facile à retrouver. Nous passerons à l’heure d’été le dernier dimanche de mars, à 2h00, puis nous repasserons à l’heure d’hiver le dernier dimanche d’octobre, à 3h00.

Ce qui m’intéresse c’est que mon code puisse connaitre cette information. Et comme je veux gérer ça dans mon backend en Java, voyons voir ce que les APIs du JDK proposent.

TLDR Toutes les informations sont disponibles via des méthodes publiques depuis le JDK 8, dans le package java.time.

C’est quoi la règle ?

Toute l’API est basée sur un objet ZoneRules associé au fuseau horaire. On y trouve les décalages horaires par rapport au fuseau UTC, les règles de calcul des transitions, ainsi que les transitions qui précèdent la mise en application de la règle actuelle.

Regardons d’un peu plus près comment est construite une règle :

ZoneOffsetTransitionRule
- month: Month
- dayOfMonthIndicator: int
- dayOfWeek: DayOfWeek
- localTime: LocalTime
- offsetBefore: ZoneOffset
- offsetAfter: ZoneOffset

Par exemple, pour notre fuseau horaire, nous avons deux règles :

Mars, 25, Dimanche, 1h00, 1h, 2h : le dimanche après le 25 mars à 1h00 UTC, le décalage passe de 1h à 2h.
Octobre, 25, Dimanche, 1h00, 2h, 1h : le dimanche après le 25 octobre à 1h00 UTC, le décalage passe de 2h à 1h.

Mais à la limite, c’est aussi bien exprimé dans le toString().

ZoneId zone = ZoneId.of("Europe/Paris");
zone.getRules().getTransitionRules().stream().forEach(System.out::println);
// TransitionRule[Gap +01:00 to +02:00, SUNDAY on or after MARCH 25 at 01:00 UTC]
// TransitionRule[Overlap +02:00 to +01:00, SUNDAY on or after OCTOBER 25 at 01:00 UTC]

OK, comme ça on a compris la règle, mais concrètement c’est quand notre prochaine transition ?

C’est quand la prochaine transition ?

Une transition, c’est un instant, un décalage avant et un décalage après. C’est donc plus concret qu’une règle.

ZoneOffsetTransition
- instant: Instant
- offsetBefore: ZoneOffset
- offsetAfter: ZoneOffset

Et pour connaître la prochaine transition, on le demande à l’objet rules de notre fuseau horaire.

ZoneId zoneId = ZoneId.of("Europe/Paris");
ZoneOffsetTransition transition = zoneId.getRules().nextTransition(Instant.now());
System.out.println(transition)
// Transition[Gap at 2022-03-27T02:00+01:00 to +02:00]

La réponse à la question en titre ("Quand est-ce qu’on change d’heure ?") est donc le 27 mars 2022. A 2h00 heure locale, le décalage passera de 1h à 2h.

Attention au piège, l’objet rules a une méthode getTransitions() qui ne peut pas être utilisée pour notre besoin. Cette méthode renvoie la liste des transitions qui ne respectent pas la règle. Pour notre fuseau horaire, ce sont les transitions qui sont antérieures à l’entrée en application de la règle actuelle en 1996.

Partout dans le monde

Je me suis trouvé confronté à cette question sur un projet IoT chez Rtone. Lorsqu’on configure un appareil, on lui envoie le décalage par rapport à l’heure UTC dans son nouveau fuseau horaire. A chaque fois qu’on déplace l’appareil, il faut lui renvoyer le décalage. Et, évidemment, sans déplacement, il faut renvoyer le décalage au changement d’heure.

Le backend doit connaître le prochain changement d’heure dans le monde et connaitre le fuseau horaire concerné. Pour ça:

// On parcourt tous les fuseaux horaires.
ZoneId.getAvailableZoneIds().stream()
      .map(ZoneId::of)
      // On ne garde que ceux qui ont une future transition.
      .filter(zoneId ->
                  zoneId.getRules()
                        .nextTransition(Instant.now()) != null
      )
      // Et on conserve celui qui a la plus petite date de transition.
      .min(
            comparing(zoneId ->
                        zoneId.getRules()
                              .nextTransition(Instant.now())
                              .getInstant()
                     )
      )
      // Enfin, on planifie l'action qui se déclenchera à la prochaine transition.
      .ifPresent(this::scheduleNextTransition);

Et le vainqueur est… America/Miquelon qui change d’heure le 13 mars 2022 à 2h00 UTC et dont le décalage passera de -3h à -2h.

Conclusion

Le point d’entrée est java.time.ZoneId qui représente un fuseau horaire dans l’API de date et heure du JDK 8. A partir de là, on récupère l’ensemble des règles (getRules()) des changements d’heure puis on demande la prochaine transition (nextTransition(Instant.now())).

Tout ça n’est public que depuis le JDK 8. Les informations étaient déjà présentes avant, mais dans des classes internes du JDK.

Reste que le nombre de pays qui pratiquent le changement d’heure est en baisse constante. Sur le planisphère ci-dessus, la couleur orange représente ceux qui l’ont pratiqué puis ont arrêté. L’Union Européenne a aussi décidé de l’abandonner, peut-être, un jour. A cause de ces décisions basée sur le bien-être des gens, le genre d’amusement présenté ici pourrait disparaître. Nos politiciens pourraient penser au plaisir des développeurs quand ils simplifient les règles.

WildFly 25, la promotion d’elytron

2022-02-28T00:00:00+00:00

Depuis la version 11, WildFly est livré avec 2 sous-systèmes de sécurité, PicketBox et Elytron. PicketBox était actif par défaut, et un script jboss-cli permettait de passer sous Elytron. Depuis WildFly 25, Elytron a été promu au rang de sous-système de sécurité par défaut.

Ce billet était initialement publié sur le site de Sewatech. Il a migré ici suite à l’abandon de la section Articles.

PicketBox

PicketBox est utilisé pour la sécurité depuis la nuit des temps. On le trouvait déjà en 2002 dans JBoss AS 3.0, sous le nom de JBoss SX.

On trouve la preuve d’une filiation forte dans la classe SecureIdentityLoginModule qui permet d’utiliser des mots de passe chiffrés dans les datasource. L’algorithme n’a pas changé, c’est toujours du Blowfish, et la clé de chiffrement est toujours "jaas is the way". J’ai fait un peu d’archéologie, pour comparer le code à une quinzaine d’années d’écart.

   // JBoss AS 3.2 (2005)
   private static char[] decode(String secret)
      throws NoSuchPaddingException, NoSuchAlgorithmException,
      InvalidKeyException, BadPaddingException, IllegalBlockSizeException
   {
      byte[] kbytes = "jaas is the way".getBytes();
      SecretKeySpec key = new SecretKeySpec(kbytes, "Blowfish");

      BigInteger n = new BigInteger(secret, 16);
      byte[] encoding = n.toByteArray();

      Cipher cipher = Cipher.getInstance("Blowfish");
      cipher.init(Cipher.DECRYPT_MODE, key);
      byte[] decode = cipher.doFinal(encoding);
      return new String(decode).toCharArray();
   }

Pour la version actuelle, j’ai un peu triché en enlevant quelques lignes de code qui corrigent 2 bugs.

   // WildFly 25 (2021)
   private static char[] decode(String secret)
      throws NoSuchPaddingException, NoSuchAlgorithmException,
      InvalidKeyException, BadPaddingException, IllegalBlockSizeException
   {
      byte[] kbytes = "jaas is the way".getBytes();
      SecretKeySpec key = new SecretKeySpec(kbytes, "Blowfish");

      BigInteger n = new BigInteger(secret, 16);
      byte[] encoding = n.toByteArray();

      //SECURITY-344: fix leading zeros
      ...

      Cipher cipher = Cipher.getInstance("Blowfish");
      cipher.init(Cipher.DECRYPT_MODE, key);
      byte[] decode = cipher.doFinal(encoding);
      return new String(decode).toCharArray();
   }

Le nom PicketBox apparait dans les modules de WildFly, mais pas dans la configuration (standalone.xml).

  <subsystem xmlns="urn:jboss:domain:security:1.2">
      <security-domains>
        ...
      </security-domains>
  </subsystem>

Passage à Elytron

Dans WildFly 10, un module org.wildfly.security.elytron est apparu, sans configuration associée. Une documentation touffue (l’export PDF fait plus de 60 pages) explique comment l’utiliser et une doc de migration (plus de 40 pages).

Le sous-système elytron est apparu dans WildFly 11, en 2017, avec une centaine de lignes de configuration.

  <subsystem xmlns="urn:wildfly:elytron:1.2" final-providers="combined-providers" disallowed-providers="OracleUcrypto">
      <providers>
        ...
      </providers>
      <audit-logging>
        ...
      </audit-logging>
      <security-domains>
        ...
      </security-domains>
      <security-realms>
        ...
      </security-realms>
      <mappers>
      </mappers>
      <http>
        ...
      </http>
      <sasl>
        ...
      </sasl>
  </subsystem>

Il faut utilise le script enable-elytron.cli pour faire la bascule. Il y a une quinzaine de lignes pour basculer une configuration standalone, 4x plus pour le domaine. Donc si ce sous-système n’est pas utilisé par défaut, c’est assez facile de l’activer.

Avec WildFly 25, le sous-système elytron est utilisé par défaut, et le sous-système security a tout simplement disparu. La doc elytron fait maintenant 250 pages ! Mais pas très pratique, avec beaucoup de code et peu de configuration.

Fonctionnalité de Elytron

Si la doc est si grosse, c’est que Elytron a beaucoup de fonctionnalités.

Il sert à la fois pour la sécurisation des interfaces de management et pour less applications. Il sert à la fois pour l’authn/authz et pour le TLS. Il gère l’auth à l’ancienne avec du LDAP, de la DB. Il gère l’auth avec token, supporte JWT et Oauth2 Il gère le stockage sécurisé des secrets, en remplacement des caveaux. Il propose beaucoup de souplesse, ce qui implique une certaine complexité, avec des couches d’abstraction .

Conclusion

Elytron apporte un vent de modernité à la sécurité de WildFly.

Mais aussi de la complexité. Alors qu’un effort est fait régulièrement pour simplifier la configuration par défaut, pour privilégier l’implicite et alléger le fichier standalone.xml, le sous-système elytron arrive avec 160 lignes ! Et chaque opération demande plusieurs lignes de script.

Passer des arguments au build de Docker

2022-01-05T00:00:00+00:00

Depuis quelques années, je gère un repository sur GitHub pour que chacun puisse faire un build à partir du code source de JBoss EAP. Récemment, j’ai voulu automatiser ce build avec Docker, sur plusieurs systèmes (Debian, CentOS, Alpine), pour plusieurs versions du JDK (8 et 11) et pour plusieurs versions de JBoss EAP.

C’est là que j’ai découvert la possibilité d’utiliser des arguments dans Dockerfile et de les passer en option de docker build. Ainsi, je peux choisir les versions du JDK et de JBoss EAP au lancement du build :

~# docker build --build-arg JDK_VERSION=8 --build-arg EAP_VERSION=7.2.3     \
                --tag hasalex/eap:7.2.3_jdk8 .

Voyons pourquoi et comment j’en suis arrivé à ce résultat…

Qu’est-ce que JBoss EAP ?

Avant de parler des arguments de build de Docker, je vais remettre en place le contexte.

JBoss EAP est un serveur d’application Java EE / Jakarta EE édité de Red Hat. Il est payant dans le cadre d’une souscription. Son équivalent gratuit est WildFly.

Le modèle économique de Red Hat est le même que pour ses distributions Linux : RHEL est un produit payant avec une souscription et Fedora est un artéfact gratuit issu d’un projet communautaire.

JBoss EAP ⇐⇒ RHEL et WildFly ⇐⇒ Fedora.

Et pourquoi faire un build soi-même ?

Parce que c’est possible !

Comme pour tout ce que fait Red Hat, JBoss EAP est Open Source. Et pouvoir accéder au code source sans pouvoir le compiler et l’utiliser, je trouve ça triste.

Il y a quelques années, j’ai regardé de plus prêt ce que Red Hat publiait et j’ai essayé de faire le build. Depuis, j’ai mis ça en forme dans un repo GitHub et visiblement c’est utile à quelques personnes. Il y a même quelques contributeurs .

Le build Docker

Dans un premier temps, j’ai préparé un fichier Dockerfile pour construire une image avec la dernière version de JBoss EAP et le JDK 11, sur un base de Debian.

# =====
FROM azul/zulu-openjdk-debian:11 as eap-build

RUN apt-get update -y                                            && \
    apt-get install -y wget unzip patch curl maven xmlstarlet

WORKDIR eap-build-master
COPY . ./
RUN ./build-eap7.sh                                              && \
    unzip -q -d /opt dist/jboss-eap-*.zip                        && \
    mv /opt/jboss-eap-* /opt/jboss-eap


# =====
FROM azul/zulu-openjdk-debian:11

RUN groupadd -r jboss -g 1000                                    && \
    useradd -u 1000 -r -g jboss -m -d /opt/jboss-eap                \
                    -s /sbin/nologin -c "JBoss user" jboss       && \
    chmod 755 /opt/jboss-eap

COPY --from=eap-build --chown=jboss:0 /opt/jboss-eap /opt/jboss-eap

WORKDIR /opt/jboss-eap
USER jboss
ENV LAUNCH_JBOSS_IN_BACKGROUND true

EXPOSE 8080
EXPOSE 9990

CMD ["bin/standalone.sh", "-b", "0.0.0.0", "-bmanagement", "0.0.0.0"]

Par la suite, j’ai voulu laisser le choix de la version à construire ainsi que la version du JDK à utiliser. L’objectif était de donner un maximum de liberté à l’utilisateur, mais sans multiplier les fichiers Dockerfile.

Faites le calcul : fin 2021 on pouvait choisir entre 36 versions mineurs et updates de JBoss EAP 7. Le build pouvant fonctionner avec tous les JDKs entre les versions 8 et 16, sur 3 systèmes Linux (Debian, CentOS et Alpine), ça fait presque 1000 possibilités.

… avec des arguments

La solution à mon problème, c’est le build argument. Ça se déclare dans le fichier Dockerfile avec l’instruction ARG, soit dans le corp du fichier de la même façon qu’une variable ENV, soit avant le FROM.

ARG JDK_VERSION=11
FROM azul/zulu-openjdk-alpine:$JDK_VERSION as eap-build

...
ARG EAP_VERSION
RUN ./build-eap7.sh $EAP_VERSION
...

Dans cette exemple, la version du JDK a une valeur par défaut et la version d’EAP est vide par défaut. Avec la commande simple, on construit donc la dernière version d’EAP avec le JDK 11.

~# docker build --tag hasalex/eap .

En passant les build arguments, on peut construire une version plus ancienne avec un JDK 8.

~# docker build --build-arg JDK_VERSION=8 --build-arg EAP_VERSION=7.2.3     \
                --tag hasalex/eap:7.2.3_jdk8 .

Conclusion

Avec les build arguments et 3 fichiers Dockerfile, on s’ouvre le choix entre près de 1000 combinaisons système / JDK / EAP.

Si vous voulez essayer, vous trouverez les scripts et les Dockerfile sur le GitHub d’eap-build.

Sortie du JDK 17

2021-11-03T00:00:00+00:00

Maintenant que la sortie d’une nouvelle version du JDK est devenu une routine, l’événement est l’arrivée d’une version LTS.

Voyons ce que cette version 17 nous apporte au niveau du langage, du runtime et des API.

Ce billet était initialement publié sur le site de Sewatech. Il a migré ici suite à l’abandon de la section Articles.

Cycle de release

Le nouveau cycle de release commence à être rodé. On a eu cinq versions STS^[1] (12 à 16), avec leurs nouveautés, leurs fonctionnalités en preview et leurs API expérimentales. Ce JDK 17 consolide ces 3 ans de travail dans une version LTS^[2].

La prochaine version LTS devait être pour le JDK 23 dans 3 ans, mais le délai sera probablement réduit puisqu’on s’oriente vers une version LTS tous les 2 ans.

Par ailleur, Oracle a annonce le retour de la gratuité de son JDK, sous certaines conditions assez peu contraignantes. Je ne suis pas sûr que ça m’incite à abandonner OpenJDK pour autant.

Pour rappel, voici une liste de distributions d’OpenJDK :

Fonctionnalités

Les nouveautés du langage Java sont bien plus allèchantes que celles du JDK 11. Il y a des choses qui peuvent réellement changer notre code, comme les records, le pattern matching ou les classes scellées.

Les records ressemblent à des java beans simplifiés et modernisés. Plus précisément, ils permettent de définir des tuples nommés.

record Person(String name, int age) {}

Le pattern matching concerne pour l’instant l’instruction instanceof. Sa syntaxe a un peu évolué pour éviter des cast.

if (shape instanceof Rectangle rect) {
    return 2 * (rect.length() + rect.width());
} else if (shape instanceof Circle circle) {
    return 2 * PI * circle.radius();
} else {
    throw new IllegalArgumentException("Unrecognized shape");
}

Le pattern matching concerne aussi l’instruction switch. Ce projet est bien plus ambitieux. Dans un premier temps, la structure du switch a été enrichie pour en faire une expression, avec un recyclage de la flèche →. Le pattern matching à proprement parler n’est qu’en preview.

return switch (shape) {

  case Rectangle rect -> 2 * rect.length() + 2 * rect.width();

  case Circle circle -> 2 * circle.radius() * Math.PI;

  default ->
    throw new IllegalArgumentException("Unrecognized shape");

};

Au niveau du runtime, les ramasse-miettes de nouvellle génération, ZGC et Shenendoah GC, sont sortis de la phase expérimentale. Leurs performances ont l’air vraiment impressionnantes. Et CMS, l’antique ramasse-miettes concurrent, a été retiré. G1 reste le garbage collector par défaut.

Au niveau des API en revanche, il y a beaucoup de petites choses, mais rien de bouleversant.

Conclusion

C’est dommage que le pattern matching ne soit pas terminé. Sinon, cette version LTS aurait pu être considérée comme réellement importante, au même niveau que les versions 5 (generics) et 8 (lambda).

A ce titre, la réduction du délai à 2 ans pour la prochaine version LTS est une bonne nouvelle, au moins à court terme. La version 21 marquera une nouvelle étape importante dans la modernisation du JDK. Rendez-vous en septembre 2023…

N’hésitez pas à nous contacter si vous souhaitez planifier une formation sur les nouveautés du JDK 17.

1. Short Term Support

2. Long Term Support

Bojo Blog

Développement avec l’IA, retour d’expérience

Mes premiers pas

L’IA avec IntelliJ

Complétion

Actions d’IA

Chat

Junie

Qualité du code

Conclusion

Afficher un historique avec Hibernate Envers

Query API d’Envers

Amélioration simple

Service d’historique

Champs et associations @XxxToOne

Associations @XxxToMany

Assemblage

Endpoint

Conclusion

Retour d’expérience, migration à Spring Boot 3

Tâches préalables

Tâches prévues

Tâches pas prévues

Conclusion

Tests d’intégration, comment vérifier que le ménage a été fait ?

Le problème

Extension JUnit

Intégration avec Spring et JPA

Améliorations

Synthèse

Comment vérifier l’envoi d’e-mails en test d’intégration ?

Docker, évidemment

Mock

Les deux mon capitaine

Une histoire de temps et de tests

On a toujours fait comme ça

Bâtisseur de dates

Moquons le maçon

Remettons l’horloge au centre du village

Rock around the Clock

Donnons du temps au temps

Un jour j’irai à New-York avec toi

Ni clou, ni vis

Au vent en emporte le temps

Quand est-ce qu’on change d’heure ?

C’est quoi la règle ?

C’est quand la prochaine transition ?

Partout dans le monde

Conclusion

WildFly 25, la promotion d’elytron

PicketBox

Passage à Elytron

Fonctionnalité de Elytron

Conclusion

Passer des arguments au build de Docker

Qu’est-ce que JBoss EAP ?

Et pourquoi faire un build soi-même ?

Le build Docker

…​ avec des arguments

Conclusion

Sortie du JDK 17

Cycle de release

Fonctionnalités

Conclusion

Champs et associations `@XxxToOne`

Associations `@XxxToMany`

Rock around the `Clock`

… avec des arguments