La Version Spring Boot 3.2 : Nouvelles Fonctionnalités et Améliorations

La dernière version de Spring Boot, la version 3.2, introduit une multitude de nouvelles fonctionnalités et améliorations destinées à améliorer l’expérience des développeurs et à étendre les capacités. Dans cet article, nous explorerons les principaux points forts de cette version, couvrant tout, depuis les améliorations de l’efficacité d’exécution jusqu’aux progrès en matière d’observabilité et de création d’images Docker.

il change la donne, révolutionnant le paysage du développement en se concentrant sur trois piliers principaux, outre quelques mises à niveau majeures de version.

• Efficacité d’exécution,
• Innovation en matière d’accompagnement client,
• Améliorations de l’observabilité

Passons à chaque aspect pour comprendre comment cette version propulse Spring Boot vers de nouveaux sommets.

1. Efficacité d’exécution

L’intégration de la prise en charge de Java 21 dans cette dernière version apporte une multitude d’avantages, notamment en tirant parti des dernières fonctionnalités du JDK. Étant donné que les applications Spring sont conçues pour un traitement prolongé et efficace, la JVM fait intrinsèquement preuve d’un haut degré d’intelligence dans la gestion de tels scénarios.

La JVM identifie habilement les zones d’exécution fréquentes et intenses, facilitant ainsi la compilation et l’optimisation ultérieure pour améliorer l’efficacité globale.

Dans le domaine du développement d’applications, nous sommes confrontés à un large éventail de besoins. Certaines applications nécessitent une faible utilisation de la mémoire et des temps de démarrage rapides, tandis que d’autres, en particulier celles traitant de tâches telles que la communication avec des bases de données ou des services HTTP, donnent la priorité à l’évolutivité.

Java et Spring se sont adaptés pour répondre aux demandes de diverses applications. Notamment, dans Spring Boot 3.2, il prend en charge les threads virtuels et le projet CRaC (Coordinated Restore at Checkpoint), offrant ainsi aux développeurs des outils supplémentaires pour répondre à différentes exigences.

1.1 Prise en charge des threads virtuels

Avant de parler de threads virtuels, comprenons ce qu’est le thread, quels changements les threads peuvent-ils apporter au traitement ?

Les threads peuvent exécuter un ensemble d’instructions à la fois, vous pouvez donc vous faire une idée, ils exécuteront simultanément les instructions et nous donneront l’efficacité. Java prend en charge le multithreading, ce qui nous donne l’avantage de pouvoir exécuter plusieurs tâches à la fois. Cela signifie qu’il utilise les ressources (cœurs du CPU). En Java, chaque méthode est allouée à un thread particulier et il s’agit d’un mappage 1:1 entre les threads Java et les threads du système d’exploitation.

Mais comme vous le savez déjà, Spring Boot est un framework permettant d’implémenter principalement le côté serveur, il y aura donc de nombreux appels à la base de données ou des conversations avec d’autres services tiers ou avec nos propres services. Ces types de requêtes doivent donc être arrêtés pour attendre la réponse d’autres services ou bases de données. celles-ci sont donc considérées comme des opérations bloquantes. Il y a donc un arrêt dans le thread qui gère l’opération de blocage. Alors vous pouvez vous poser la question : est-ce évolutif ? Ou est-ce que cela peut être amélioré ?

Comme le suggèrent les experts, il y aura deux solutions : l’une consiste à augmenter les ressources de mémoire ou de processeur (mise à l’échelle verticale) et l’augmentation du nombre de serveurs (mise à l’échelle horizontale), une autre consiste à utiliser la programmation asynchrone, mais bien sûr, cela présente certains inconvénients.

Comprenons maintenant les threads virtuels

Si nous ne bloquions pas les threads réels et ne générions pas des millions de threads à partir des threads actuels ? et comment attribuer la tâche à l’un des threads générés ? Oui! c’est ce que nous offre Java 21. Cela nous permet d’écrire du code bloquant sans soucis majeurs d’évolutivité.

Dans Java 21, une tâche est liée à un thread réel avec un thread virtuel attaché et si nous devons effectuer une opération de blocage, elle sera déplacée vers le tas et une fois la tâche terminée, elle sera ensuite déplacée vers liste d’attente pour le fil de discussion auquel il était lié.

1.2 Projet CRaC

Le projet CRaC (Cooperative Restore at Checkpoint) se concentre sur la recherche de moyens de coordonner les programmes Java en créant des instantanés ou des images (checkpointing) d’une instance Java en cours d’exécution. Le but de ces instantanés est de résoudre potentiellement les problèmes liés aux temps de démarrage et de préchauffage. Essentiellement, le projet vise à développer une API universelle indépendante des mécanismes spécifiques, fournissant un moyen standardisé d’informer les programmes Java des événements de points de contrôle et de restauration.

L’objectif principal est d’établir une méthode cohérente permettant aux applications Java de savoir quand elles sont vérifiées ou restaurées. En plus de cet objectif principal, le projet consiste à explorer les possibilités d’intégration avec les mécanismes de point de contrôle/restauration existants tout en considérant également le développement de nouveaux mécanismes. En outre, la recherche comprend l’étude des modifications apportées à la machine virtuelle Java (JVM) et au kit de développement Java (JDK) pour optimiser la taille des images créées et garantir leur exactitude.

Essentiellement, CRaC cherche à améliorer l’efficacité et la fiabilité des programmes Java en introduisant des mécanismes coordonnés pour capturer et restaurer leurs états d’exécution.

2. Innovation en matière d’assistance client

Spring Boot a simplifié ses communications avec les services et bases de données externes, en fournissant des API, cela inclut les appels de base de données et les communications de services externes à l’aide d’un client Web ou du modèle Rest Template. (Le client Web est utilisé pour écrire des appels non bloquants alors que Rest Template est utilisé pour écrire des appels bloquants). Dans cette version, Spring Boot a introduit JDBC Client et Rest Client, deux nouveaux supports clients.

2.1 Prise en charge de RestClient

La version introduit la prise en charge de la nouvelle interface RestClient, offrant un style fonctionnel bloquant l’API HTTP avec une conception similaire à WebClient. Il encourage les développeurs à considérer RestClient comme une alternative à RestTemplate, soulignant la nécessité d’une nouvelle approche.

Voici un exemple d’utilisation de RestClient :

@Service
public class ExempleService {

    private final RestClient restClient;

    public ExempleService (RestClient.Builder builder) {
        this.restClient = builder
                .baseUrl("<https://example_base_url.com/>")
                .build();
    }

    public Collection<Exemple> findAll() {
        return restClient.get()
                .uri("/exemple")
                .retrieve()
                .body(new ParameterizedTypeReference<>(){});
    }

    public ResponseEntity<Exemple> findById(Long id) {
        return restClient.get()
                .uri("/example/{id}", id)
                .retrieve()
                .toEntity(Post.class);
    }

}

En effet, Spring Boot 3 a introduit l’interface HTTP client. Nous pouvons définir des appels HTTP dans une interface pour omettre le code. Auparavant, cela était basé sur le Web Client , mais maintenant, avec cette version, cela est basé sur le Rest Client.

2.2 Prise en charge du client JDBC

Le modèle JDBC est une abstraction utile pour simplifier les interactions avec les bases de données. Cependant, lors de la création de services CRUD de base impliquant la création, la lecture, la mise à jour et la suppression de ressources, l’utilisation de modèles JDBC peut impliquer une complexité inutile. Cette verbosité résulte du traitement de détails complexes tels que les mappeurs de lignes et le mappage des colonnes aux champs.

Malgré sa complexité, le modèle JDBC offre aux développeurs un contrôle total sur SQL, une fonctionnalité très appréciée des développeurs. Pour relever les défis posés par ces complexités, Spring Boot 3.2 introduit le client JDBC. Ce nouvel ajout présente une API fluide, facile à comprendre et à lire. Un avantage notable est sa configuration automatique, simplifiant le processus d’obtention d’une instance sans complications inutiles.

Illustrons cela avec un exemple. Considérez une classe Repository qui inclut des méthodes CRUD pour lire et conserver des données dans une base de données. Dans cet exemple, l’instance du client JDBC est injectée à l’aide d’une injection de constructeur, contribuant ainsi à améliorer la lisibilité du code grâce à l’utilisation de l’API fluide.

@Repository
public class PostRepository {

    private final JdbcClient jdbcClient;

    public PostRepository(JdbcClient jdbcClient) {
        this.jdbcClient = jdbcClient;
    }

    public List<Example> findAll() {
        return jdbcClient.sql("SELECT * FROM example")
                .query(Example.class)
                .list();
    }

    public Optional<Example> findById(String id) {
        return jdbcClient.sql("SELECT * FROM Example WHERE id = :id")
                .param("id", id)
                .query(Example.class)
                .optional();
    }

    public void create(Example example) {
        jdbcClient.sql("INSERT INTO Example(id, data) values(?,?)")
                .params(List.of(example.id(), example.Data()))
                .update();
    }


    public void delete(String id) {
        jdbcClient.sql("delete from Example where id = :id")
                .param("id", id)
                .update();
    }

}

3. Améliorations de l’observabilité

Dans Spring Boot 3.0, une amélioration significative a été l’introduction d’une API d’observation unifiée, utilisée à l’origine en interne par le framework et désormais accessible aux développeurs. Cette API permet l’instrumentation des applications, permettant l’exécution de diverses actions pour chaque instrumentation, telles que l’émission de messages de log, le démarrage et l’arrêt de minuteries, l’incrémentation de compteurs et la signalisation d’erreurs.

Auparavant, pour intégrer des métriques et du traçage, les développeurs devaient instrumenter leurs applications à deux reprises, ce qui entraînait une redondance potentielle du code et décourageait la mise en œuvre de l’observation. Cependant, avec Spring Boot 3.2, les annotations de Micrometer telles que @Timed, @Counted, @NewSpan, @ContinueSpan et @Observed peuvent désormais être utilisées directement. Ces annotations sont automatiquement configurées si AspectJ est inclus dans le chemin de classe, obtenu en ajoutant la dépendance spring-boot-starter-aop au projet. Cette approche rationalisée simplifie le processus d’observation et élimine le besoin de configuration manuelle, ce qui le rend plus pratique pour les développeurs.

En résumé, Spring Boot 3.2 incluait l’efficacité d’exécution avec la prise en charge des threads virtuels et le concept CraC, puis il a introduit deux nouvelles abstractions client telles que Rest Client et le JDBC Client et a également simplifié et amélioré l’observabilité.