Lors de la conférence Devoxx France 2026, j’ai assisté à un talk venu tout droit d’une comète : la présentation de TamboUI (prononcer “tambouille”), un tout nouveau framework Java dédié aux interfaces utilisateur dans le terminal (ou Terminal User Interface TUI en anglais, plus anciennement connus sous le nom de Text-based User Interface).

Derrière ce nom amusant, deux pointures de l’écosystème Java : Cédric Champeau (longtemps lead de Gradle, aujourd’hui dans les équipes Micronaut et GraalVM chez Oracle) et Max Rydahl Andersen (créateur de JBang, co-dirige le projet Quarkus chez Red Hat). Autant dire que la généalogie du projet est sérieuse.

Cet article revient sur les motivations, l’architecture et les APIs de TamboUI.

Conférence : Devoxx France 2026
Date : 24 avril 2026
Speakers : Riad Maouchi (Société Générale CIB) et Christopher Etancelin (Société Générale)
Format : Tools in action (30 min)
Repo GitHub : https://github.com/christopher-etancelin/jcstress-devoxx-demo

Au cours de ce Tools in action, Riad et Christopher nous font découvrir un outil bien pratique à utiliser sur notre code multi-threads. Maintenu par Aleksey Shipilëv (AWS), Java Concurrency Stress (JCStress) est le framework officiel d’OpenJDK permettant de reproduire des bugs de concurrence d’accès que d’autres outils n’arrivent pas à détecter. Il met à l’épreuve le code Java en explorant de manière systématique les différents entrelacements possibles entre threads. Il peut ainsi faire émerger des bugs invisibles aux tests unitaires JUnit classiques : problèmes de visibilité, d’ordre d’exécution ou d’atomicité.

Conférence : Devoxx France 2026
Date : 24 avril 2026
Speakers : Clément de Tastes (SCIAM) et Rémi Forax (Université Gustave Eiffel)
Format : conférence (45 min)
Repository GitHub : mandelbrot-valhalla

Ce talk sur le futur de Java commence par nous plonger dans l’univers des fractales.

Le chou-fleur romanesco est une structure fractale : son motif se répète quel que soit le niveau de zoom. Clément a développé l’application JavaFX MandelbrotFx permettant d’afficher des fractales, dont la plus connue est très certainement la fractale de Mandelbrot.

L’implémentation Java de l’algorithme extraite de MandelbrotFractal.java utilise les types primitifs double et int. Efficace, cette implémentation est relativement difficile à comprendre. Pour améliorer sa maintenance, on peut utiliser des record en définissant le type Complex. Plus propre, ce code est cependant dix fois plus gourmand en ressources qu’avec les primitives. Beau, mais cher. C’est là où les Value Types vont venir à notre rescousse.

Lors de la conférence Devoxx France 2025, j’ai participé à un hands-on lab de 2h intitulé Sortir des ORMs avec jOOQ. Acronyme de « Java Object Oriented Querying », jOOQ se présente comme une alternative à JPA permettant d’écrire des requêtes SQL en Java via une fluent API. Animé par Sylvain Decout et Samuel Lefebvre, cet atelier visait à migrer une application Spring Boot / JPA vers jOOQ à l’aide du starter Spring Boot pour jOOQ. Pour les curieux, le repo de l’atelier est disponible sur Github : jooq-handson.

Fort de cette découverte, je me suis à mon tour prêté à l’exercice de migrer vers jOOQ la couche de persistance Spring Data JPA de l’application démo Spring Petclinic. Un nouveau fork est né : spring-petclinic-jooq. Bienvenue à ce dernier dans la communauté Spring Petclinic.

L’usage de jOOQ se rapproche de l’utilisation de JdbcTemplate. Le développeur maitrise le nombre de requêtes envoyées à la base de données relationnelle. Ce qui les différencie, c’est la syntaxe : pas de SQL, mais une API Java fluide et type-safe spécifique à jOOQ qu’il va falloir appréhender. Rassurez-vous, cette API se rapproche du SQL : on y retrouve les mots clés select, update, insertInto, where, from, join, on, as… A ceux-ci, on ajoute des mots clés spécifiques à jOOQ : paginate, fetch, convertFrom … La documentation de jOOQ est très complète. On y apprend comment écrire des requêtes complexes à base de window function ou de Common Table Expressions (CTE) et comment utiliser des fonctionnalités avancées de SQL que peu de frameworks ORM supportent nativement : JSON functions, PIVOT, MERGE, UNION …

Cet article a pour objectif d’expliquer les étapes adoptées pour migrer l’implémentation Spring Data JPA des repository vers jOOQ. Des exemples de code avant / après y sont proposés.

Date : 16 avril 2025
Conférence : Devoxx France 2025
Speaker : José Paumard (Oracle)
Format : Conférence 45 mn
Support : slides sur Speakerdeck / replay Youtube

Java Developer Advocate chez Oracle, José Paumard nous présente la nouvelle API Gatherers qui, depuis Java 24, vient se greffer sur l’API Stream Java sortie il y’a 11 ans avec Java 8.

Tout comme l’API Collector, José commence par rappeler que l’API Gatherers est indépendante de l’API Stream. Cette API a été introduite dans Java via la JEP 485 Stream Gatherers conduite par Viktor Klang. Les plus curieux pourront regarder la vidéo Youtube du Deep Dive qu’a animé Viktor lors de la conférence JavaOne qui s’est tenue en mars 2025.

L’article The Gatherer API permet également d’approfondir votre étude des Gatherers. Notez que le site dev.java permet désormais d’exécuter des snippets Java (pas directement dans le navigateur, mais sur un serveur Cloud).

Toutes les classes et interfaces de l’API Gatherers ont été ajoutées au package java.util.stream.

Conférence : Devoxx France 2025
Date : 17 avril 2025
Speakers : Cyrille Martraire (Arolla), Eric Le Merdy (QuickSign) remplaçant de Christian Sperandio (Arolla)
Format : Conférence (45mn) / Replay Youtube

Cette conférence a pour objectif d’ouvrir les portes en nous donnant les clés de l’architecture. Pour seconder Cyrille, Eric a du remplacer Christian au pied levé.
Un constat est posé. Sur les dix dernières années, les systèmes ont changé : ils sont devenus modulaires, de plus en plus distribués. La modularité permise par le Cloud permet de répartir la charge. Il y’a de plus en plus d’interconnexions entre briques applicatives.
L’architecture bouge tout le temps, évolue constamment.

Que doit-on savoir ? Pour commencer, on ne saura jamais tout et il faudra vivre avec. Personne ne sait tout. Même le plus capé des architectes.

Comme fil conducteur, Cyrille et Eric prennent un exemple réel issu du monde des télécommunications.
Pour cahier des charges, le client précise que le système va recevoir des fichiers chaque minute et doit les intégrer tous les 15mn. Contexte : ces fichiers viennent d’équipements télécom.

Conférence : Devoxx France 2025
Date : 17 avril 2025
Speaker : Sébastien Deleuze (Broadcom)
Format : Conférence (45 mn) / Replay Youtube

Sébastien est Core Commiter sur Spring Framework. Il intervient également sur des sujets transverses au portfolio Spring : support de Kotlin, null-safety (avec JSpecify) et les sujets d’optimisation. Dans ce talk, il a pour ambition de nous montrer comment améliorer l’efficacité de 80% des applications Spring, que ce soit de nouvelles applications ou des applications Legacy.

Les raisons d’améliorer l’efficacité de nos applications sont multiples :

• Baisser le cout de run des applications
• Développement durable pour diminuer la consommation d’énergie, de mémoire et de CPU
• Optimiser les applications pour les containers (sur le Cloud ou OnPremise)

Pour arriver à nos fins, Sébastien nous propose 3 technologies :

1. CDS : techno relativement vieille mais qui s’est améliorée au fil des versions de Java
2. AOT cache : Java 24 permet d’utiliser l’AOT cache qui est une version améliorée CDS. Sébastien prédit l’exploision de AOT Cache avec la LTS Java 25
3. AOT cache with profiling : technologie expérimentale et prometeuse

Conférence : Devoxx France 2024
Vidéo Youtube : https://www.youtube.com/watch?v=KeM1cjKiMr4
Date : 18 avril 2024
Speakerines : Pauline Rambaud et Anne-Laure de Boissieu (Bedrock Streaming)
Format : Conférence (45mn)

Déjà donnée à plusieurs reprises dans différents meetups et conférences, Pauline et Anne-Laure ont repensé spécialement cette présentation pour Devoxx France. Quel honneur !

Afin de démontrer à l’assistance qu’un commentaire laissé dans une revue de code peut amener de la confusion, nos deux speakerines commencent leur show en nous montrant une Pull Request sur le repo git de leurs slides reveal : une simple émoticône. Mal interprétée, elle entraine un biais de communication.

C’est quoi la revue de code ?

Développeuses GO, Anne-Laure et Pauline rappellent que la revue de code fait partie intégrante du métier de développeur. Elle consiste à examiner le code écrit par un autre développeur afin d’en améliorer la qualité, détecter les bugs et s’assurer du respect des normes de codage. Il existe différents types de revue. Au cours de cette présentation, elles se focaliseront sur les revues centrées sur le delta du code écrit pour corriger bug ou implémenter une feature.

Conférence : Devoxx France 2024
Date : 17 avril 2024
Speakers : Damien Lucas (OnePoint)
Format : Conférence (45 mn)
Slides : https://dlucasd.github.io/la-doc-va-bien-ne-t-en-fais-pas/devoxx/#/
Vidéo Youtube : https://www.youtube.com/watch?v=zQ0A75HqFuA
Repo GitHub : https://github.com/dlucasd/la-doc-va-bien-ne-t-en-fais-pas

La documentation, sujet atemporel. Travaillant sur des projets en TMA, Damien faisait le constat suivant : d’un projet à l’autre, la structure, l’organisation et le niveau d’informations de la documentation diffèrent. De temps à autres, Damien assistait à des réunions visant à restructurer la documentation. Chaque participant a sa vision. Trouver un consensus n’est pas facile.
Damien s’est ainsi demandé s’il n’existait pas clé en main un template de rédaction de la documentation, si possible Open Source et reconnu par la communauté des dévs et architectes.

Au cours de ses recherches, il est tombé sur le framework arc42 créé en 2005 par 2 allemands : Gernot Starke et Peter Hruschka. Ce template se focalise sur l’architecture des logiciels et des systèmes. Plusieurs formats sources sont possibles en téléchargement depuis la page https://arc42.org/download : asciidoc, markdown, latex, Word, Confluence, html, Doxygen, IBM Rhapsody … Voici par exemple le template arc42 pour Word : arc42-template-FR-withhelp-docx.zip

Damien a une préférence pour l’asciidoc qui permet d’avoir une approche docs-as-code : on peut le commiter dans un repository git puis générer un document au format souhaité (ex : PDF)

Les templates arc42 au format asciidoc (extension .adoc) sont disponibles sur le repo GitHub arc42-template: une dizaine de langues est supportée dont le français.

Ce template nous guide et nous pose les bonnes questions :

1. Contenu : que faut-il documenter ?
2. Motivation : pourquoi documenter et pour qui ?
3. Représentation : comment documenter ? Faut-il préférer un diagramme ou une liste à puce ?

Arc42 propose de documenter une application en 12 chapitres. Chaque chapitre est lui-même généralement composé de 3 sous-parties.
Dans de ce talk, Damien s’appuie sur un projet fictif pour illustrer chacun des 12 chapitres. Ce projet consiste à développer une application de billetterie pour les JO. Il en profitera pour nous présenter des outils de génération de diagrammes (PlantUML et Mermaid), des outils de modélisation (C4 et Structurizr) et des outils de génération de documentation (avec CLI et donc intégrable à la CI).

Le live coding qui rendra vos applications plus pérennes

Conférence : Devoxx France 2024
Date : 19 avril 2024
Speakers : Julien Topçu ( Shodo)
Format : Conférence (45mn)
Repo GitLab : https://gitlab.com/beyondxscratch/hexagonal-architecture-java-springboot
Vidéo Youtube : https://www.youtube.com/watch?v=-dXN8wkN0yk

Cette session de live coding se déroule dans l’univers de Starwars et commence par une citation de Maitre Yoda.

En 45mn, Julien doit développer le système Rebels Rescue visant à reconstituer des flottes de sauvetage. N’en déplaise à l’Empire, les technos seront Spring Boot et Java 21.

A cet effet, il s’appuiera sur l’API publique SWAPI permettant d’accéder à un référentiel de vaisseaux à disposition. L’application sélectionne les vaisseaux qui permettent d’effectuer la mission de sauvetage. Le code source est disponible dans le repo GitLab de Julien : hexagonal-architecture-java-springboot

Julien commence par rappeler les inconvénients d’une architecture 3-tiers basée sur le triptyque Contrôleur -> Service -> Persistance