{ site.name }}

“100 000 threads en Java ? Impossible !” C’est ce que j’entends souvent. Pourtant, depuis Java 21, c’est devenu réalité grâce aux Virtual Threads (projet Loom).

On ne sait vraiment où on va que quand on sait d’où l’on vient.

C’est pourquoi j’ai décidé, pour comprendre pourquoi c’est révolutionnaire, de ré-aborder les bases avec vous : qu’est-ce qu’un thread, au juste ?

Et histoire de replonger dans les entrailles de la machine, un peu d’assembleur sera nécessaire, car oui même le C nous cache des choses ! Si vous pensiez que C était un langage de bas niveau vous allez être déçu. Mais ne vous en faites pas, je vais essayer de rendre cela le plus digeste possible.

Et donc nous répondrons à la question qu’et-ce un thread ?

Spoiler : ce n’est ni une unité de calcul, ni une magie noire. C’est bien plus simple (et bien plus malin) que ça.

Dans cet article, nous allons :

• Plonger dans les entrailles du processeur (asm x86 linux, registres, pile, RIP, RSP…).
• Comprendre comment Linux gère les threads (clone(), context switch…).
• Revoir comment Java s’accomodait des threads jusqu’à Java 21
• Voir pourquoi Java 21 change la donne avec les Virtual Threads.
• Illustrer avec des exemples concrets en Java.

Prêt ? C’est parti.

Onze ans que j’utilise Lombok dans tous mes projets Java. Onze ans de @Builder, @Getter, @EqualsAndHashCode sans jamais écrire une ligne de boilerplate. Onze ans de bonheur - jusqu’au jour où j’ai voulu générer une Javadoc 100% propre sur un projet Java 25 avec un Lombok récent.

Le constat : une Javadoc vide. Des builders fantômes. Des constructeurs introuvables. Un plugin Maven qui se plaint de tout sans rien résoudre.

Le problème est fondamental : Lombok est un processeur d’annotations qui modifie l’AST (arbre de syntaxe abstrait) du compilateur Java pendant la compilation. Le bytecode final contient bien les méthodes générées, mais le code source, lui, reste inchangé. Or javadoc lit le code source, pas le bytecode. Vos @Builder, @UtilityClass et autres annotations disparaissent dans ce gouffre - et avec eux, toute la documentation soigneusement rédigée sur vos champs.

Jusqu’ici, je me contentais d’une Javadoc approximative. Halte à l’approximation.

J’ai cherché. ChatGPT m’a proposé des versions de Lombok incompatibles avec Java 25. GitHub Copilot m’a donné des configurations de plugins qui n’existent pas. Stack Overflow affiche des réponses de l’ère Java 8. J’ai dû faire “à l’ancienne” : réfléchir, tester, corriger, recommencer. Le tout sans Generative AI.

La solution que j’ai construite passe par une phase delombok (génération du code source et non pas du bytecode), une configuration Maven précise pour Java 25, un profil dédié pour ne pas casser les IDE, des scripts Groovy pour injecter la Javadoc manquante sur les classes générées et en bonus, deux skills pour que vous n’ayez pas à refaire ce chemin.

Ce n’est pas simple. Mais ça fonctionne.

// Rien n'empêche d'appeler ça à l'envers. Le compilateur ne dit rien.
public User createUser(String firstName, String lastName, String email, String phone) { /*...*/ }

Voilà le genre de code qu’on écrit depuis des années sans se poser de questions. Et pourtant il y a un bug potentiel dans chaque appel : l’ordre des paramètres. Mais il y a pire : ces quatre String ne représentent pas la même chose. Un prénom, un nom de famille, un email, un numéro de téléphone : ce sont des concepts métier distincts, avec leurs propres règles de validation, leurs propres contraintes. Et vous les représentez tous avec le même type.

C’est le code smell qu’on appelle Primitive Obsession. Et depuis Java 16, on n’a plus d’excuse pour le laisser traîner.

Tout le monde connait (ou doit connaitre) les API Collections offertes par le JDK et notamment les interfaces de haut niveau : Collection, Map et très certainement les interfaces spécialisées comme List ou Set.

Bien qu’ayant subi un léger lifting lors du passage à Java 8, notamment grâce à (ou à cause de) la Stream API, cette API historique souffre toujours de divers manques et d’une verbosité parfois pénible.

Il n’est donc pas rare de voir Guava ou Apache Commons Collections ajoutées aux dépendances d’un projet, chacune avec ses inconvénients : Guava embarque tout (y compris ce qu’on ne veut pas), et Apache Commons Collections ne supporte pas les lambdas, ayant été conçue avant Java 8.

Je vais donc vous présenter Eclipse Collections, une API légère, performante et vraiment efficace qui gagne à être connue. Et je vais vous montrer concrètement pourquoi, une fois qu’on y a goûté, on ne revient pas en arrière.

Si comme moi tu en as assez de faire des programmes types “ligne de commande” en Java et d’être obligé de les lancer avec ce genre de choses :

$ java -jar demo-app-v1.0.0-SNAPSHOT.jar arg1 arg2 arg3`

Ce petit article devrait te plaire. Tu pourras alors faire directement ça :

$ ./demo-app arg1 arg2 arg3

Appétissant !

Dans ce petit tutoriel, je vais donc générer un exécutable :

• pour Linux et MacOSX,
• pour Windows, un .EXE,
• sous forme de Runnable JAR, classique.

Cela nécessite toutefois la présence d’un Runtime JAVA (JRE et/ou JDK) sur la machine qui l’exécutera, bien qu’il existe aussi des solutions pour embarquer un JRE.

Les solutions, que je vais décrire, n’utilisent pas GRAALVM et sa compilation native.

Ce tutoriel Quarkus-JPA-PostgreSQL met en oeuvre :

• une API Rest partielle (GET) avec JAX-RS et Quarkus sur une source de données JPA
• des tests unitaires
• des tests d’intégration au niveau API (http) avec un PostGreSQL lancé par un plugin maven Docker
• une distribution native, compilée avec GraalVM et une image docker de l’application compilée

Réalisé sous Linux Mint 19 mais devrait convenir à de nombreuses distributions, voire à Windows.

Java 12 est sorti le 20/03/19, apportant une nouvelle façon d’écrire des structures de contrôle switch/case. Cela m’a donné une idée, certes un peu étrange, de revoir le traditionnel switch/case d’un point de vue programmation fonctionnelle en s’appuyant sur des lambdas et une petite classe Switch, le tout en JAVA 8 !

Attention toutefois, il est certain que cette approche est beaucoup moins performante qu’un switch/case classique, mais je ne renonce pas à la beauté du geste.

Versions de cet article :

• 04/10/2019 : première publication.
• 26/02/2020 : suite à idée judicieuse postée sur les forums “developpez.com”, voir la partie “Let’s go further …”

• Version 1 parue le 16/12/2017
• Version 2 parue le 06/08/2018 : accès concurrents, PermGen / Meta spaces, Holder interne

L’objectif de ce billet est de présenter une implémentation simple en Java du pattern Singleton.

Je ne traiterai donc pas de l’utilité ni des recommandations d’usage liées à celui-ci mais bien de mise en oeuvre (codage pour les intimes) en Java Standard Edition (JSE).

Cet article va vous permettre de découvrir Deltaspike Data Module, une alternative à Spring Data dans le monde CDI et dans notre cas en CDI 2.0.

Cette accroche est parlante pour ceux qui connaissent Spring Data mais peut-être pas pour les autres : Deltaspike Data va permettre d’avoir très simplement une fonctionnalité de CRUD (Create, Read, Update, Delete) sur des entités JPA et bien plus encore en vous faisant économiser énormément de temps de développement et de bugs potentiels !

Comme tout système s’appuyant sur des inputs, il est très important de contrôler les arguments des méthodes quand on élabore une API, qu’elle soit locale sous forme de JAR ou distante via un service REST, afin de non seulement la rendre plus robuste et stable mais aussi de se prémunir de certaines attaques.

Cependant, en Java de base, c’est particulièrement laborieux, rébarbatif et cela engendre une fainéantise exacerbée. Conséquences directes et désastreuses : baisse de la qualité, de la robustesse du code et créations potentielles de failles de sécurité.

Cet article tente de faire le tour de la question, sans prétention, en ratissant assez large. C’est à dire en allant de Java classique jusqu’à Bean Validation et JAX-RS, en passant par une implémentation spécifique “Faite Maison”.

NodeJS se targue de pouvoir monter en quelques lignes de code un simple serveur HTTP. Effectivement, créer ce genre de serveur est vraiment simple et particulièrement utile pour du déploiement dans le Cloud.

Et Java dans tout ça ? A la traîne ? Has-Been ?

“Si à 50 ans t’as pas de Rolex et/ou si tu sais pas faire de TypeScript, t’as raté ta vie !”

Fort heureusement, je vais vous montrer qu’avec JShell, apparu avec Java 9, en 10 lignes de code environ, vous obtiendrez un serveur HTTP Asynchrone, performant, en ayant à portée de main tout ce que vous offre Java 10, ses modules, ainsi qu’historiquement, toutes les bibliothèques JAR de son écosystème !

“Il me faut un repo Maven dédié !”. Voilà ce qui m’est venu en tête quand j’ai dû changer de machine récemment alors que tous les artefacts maven que je produisais étaient capitalisés dans le .m2/repository de mon home. Autant dire “Pas capitalisés”.

Bien sûr, j’utilise un repo Nexus au boulot mais je change d’activité et je vais devenir plus mobile, il me faut donc une solution.

J’aurais pu prendre une image Docker et la déployer sur AWS ou équivalent : la solution de facilité qui demande toutefois un peu de “ressource” financière.

Et je le vois, là, rose, toutes diodes allumées, connecté à ma box, servant de proxy Squid de temps en temps. Mon Raspberry PI 1, je l’entends encore me dire “Moi je peux, moi je peux, moi je peux !” en trépignant dans son joli boitier.

Comme tout bon développeur Java, je suis un gros consommateur des solutions fournies par l’Eclipse Foundation. Je ne vais en citer que quelques-unes : Eclipse IDE, EclipseLink, Eclipse GlassFish, Jetty, Eclipse EGit, Eclipse Maven Integration, etc.

Il était donc temps, au lieu d’attendre en ronchonnant qu’un patch ne soit développé, de contribuer en fournissant un correctif à un projet.

Ce court billet va vous présenter quelles instructions sont exécutées dans vos classes Java, lorsque que vous en réclamez une instance.

Dans mon parcours professionnel, j’ai été formateur de jeunes développeurs pendant sept années. Ces derniers venaient d’horizons différents, parfois sans aucune compétence en terme de programmation.

Afin de rendre ludique l’apprentissage des fondamentaux de l’algorithmique et de Java, je les ai fait participer à la création d’un jeu video : Xenon Reborn, inspiré du célèbre jeu Xenon des Bitmap Brothers.

Je vais vous présenter succinctement les deux façons natives en JPA pour déclarer des NamedQuery.

On verra alors que ces deux solutions ont des défauts et je vous proposerai alors une 3ème qui me paraît plus satisfaisante, fondée sur une “enum”.

Dans ce billet, je vais présenter la bibliothèque Lombok dont je ne peux plus me passer pour mes développements Java. Cela fait maintenant plus de 4 ans que je l’utilise et tout n’est pas rose. Ce sera donc l’occasion de partager aussi certaines recommandations.

J’en donne une : n’utilisez pas @Data et je vais vous expliquer pourquoi. Un peu de patience.