Développement Java pour des systèmes faits pour durer

Pourquoi Java reste un choix solide pour les backends critiques

Les atouts de Java sont rarement spectaculaires, et c'est justement l'intérêt. Un typage statique fort, une bibliothèque standard mature, des décennies d'outillage et l'un des environnements d'exécution les plus optimisés qui soient en font un excellent choix pour des systèmes qui doivent fonctionner correctement pendant des années et être maintenus par des équipes qui changent.

Le langage a aussi beaucoup évolué depuis Java 8. Records, interfaces scellées, pattern matching pour switch, text blocks et virtual threads (finalisés dans Java 21) suppriment une bonne partie du code verbeux qui faisait sa réputation. Les virtual threads, en particulier, rendent à nouveau viable le modèle simple « un thread par requête » pour les charges d'entrées/sorties très concurrentes, sans imposer la programmation réactive à toute la base de code.

Pour la plupart des développements backend, nous associons Java à Spring Boot, mais nous savons aussi quand des options plus légères comme Quarkus ou Micronaut sont plus pertinentes, par exemple pour des fonctions serverless à démarrage rapide ou des conteneurs à mémoire limitée.

Notre façon de travailler avec Java

Nous ciblons la version LTS actuelle (Java 21, ou Java 17 lorsqu'une contrainte de plateforme l'impose) et garantissons des builds reproductibles avec Gradle ou Maven, une toolchain figée et le verrouillage des dépendances. Le style de code et l'analyse statique s'exécutent dans la CI à chaque commit, pas seulement avant les mises en production.

Les tests épousent la forme du système : des tests unitaires rapides avec JUnit 5 et AssertJ, des tests d'intégration contre de vraies bases de données et de vrais brokers de messages grâce à Testcontainers, et des tests de contrat aux frontières entre services. Cela nous permet de refactorer en confiance, ce qui compte davantage dans une base de code Java à longue durée de vie que n'importe quel choix de conception isolé.

• Organisation des packages par domaine avec des frontières de modules claires, vérifiées par ArchUnit
• Données immuables avec les records et gestion explicite des valeurs nulles aux frontières des API
• Logs structurés, métriques et traces dès le premier déploiement
• Images de conteneurs construites avec Jib ou des Dockerfiles en couches pour des déploiements rapides et légers

Performance et fiabilité de la JVM

La plupart des problèmes de performance Java que nous rencontrons ne viennent pas de la JVM elle-même, mais de requêtes N+1, de caches non bornés, d'appels bloquants dans des pools de threads ou de heaps surdimensionnés. Nous commençons par mesurer, avec JDK Flight Recorder, async-profiler et les métriques de production, avant de toucher à la moindre configuration.

Lorsqu'un réglage s'impose, nous choisissons le garbage collector en connaissance de cause (G1 pour la plupart des services, ZGC lorsque des pauses courtes sont essentielles), dimensionnons le heap en fonction des limites du conteneur et vérifions que la JVM est bien consciente de son conteneur. L'objectif : une latence prévisible sous charge réelle, vérifiée par des tests de charge plutôt que supposée.

Reprendre et faire évoluer des bases de code Java existantes

De nombreuses organisations font tourner des systèmes importants sur Java 8 ou 11, souvent avec des frameworks et des dépendances obsolètes qui ne reçoivent plus de correctifs de sécurité. Nous reprenons régulièrement ce type de base de code : nous commençons par évaluer le build, l'arbre de dépendances, la couverture de tests et le processus de déploiement, puis proposons un chemin de migration ordonné par niveau de risque.

Les migrations se font de manière incrémentale. Nous rendons d'abord le build reproductible et ajoutons des tests de caractérisation autour des comportements critiques, puis franchissons les versions LTS une à une en gardant l'application déployable à chaque étape. Des outils comme OpenRewrite automatisent une grande partie des changements mécaniques, notamment la migration de l'espace de noms javax vers jakarta qui accompagne généralement une migration vers Spring Boot 3.

Si le système a besoin d'une restructuration plus profonde, par exemple le découpage d'un monolithe, nous l'abordons dans le cadre de notre offre de développement backend et API, en n'extrayant des services que lorsque le bénéfice opérationnel ou organisationnel est évident.

Quand Java n'est pas le bon choix

Java n'est pas toujours la réponse. Pour de petits backends-for-frontends étroitement liés à une application web en TypeScript, Node.js limite souvent les changements de contexte pour l'équipe. Pour des scripts ponctuels ou de l'exploration de données, Python est généralement plus pratique. Nous vous dirons quand nous pensons qu'un autre environnement d'exécution convient mieux à votre situation.