La JCON Europe 2025 s'est tenue cette année dans une ambiance particulière : celle des 30 ans de Java. Si les challengers se succèdent, Java continue d'évoluer à son rythme, s'adaptant aux nouvelles réalités du développement tout en conservant ce qui fait sa force : sa stabilité et la richesse de son écosystème.
Pendant quatre jours intenses (un jour d'ateliers et trois jours de conférences), plus de 1000 participants ont pu assister à une centaine de sessions réparties sur quatre tracks parallèles.
Entre nostalgie et regard vers l'avenir, cette édition a été marquante à plus d'un titre.
À titre personnel, je n'ai pu assister qu'à la première journée de conférence. Voici donc un compte rendu de cette première journée qui vous donne néanmoins un bel aperçu de la richesse de cette conférence européenne en terres germaniques.
Un événement pensé pour favoriser les échanges
Richard Fichtner, co-organisateur de l'événement, a présenté lors du kickoff les nouveautés de cette 10ème édition.
Parmi elles, un "espace spatial" dédié aux discussions informelles. Le concept est simple mais efficace :
"Si vous désirez parler mais ne savez pas qui aborder, allez dans cet espace. Et si vous y allez, c'est pour discuter."
En effet, l’intérêt de participer à une conférence n’est pas uniquement dans les talks proposés (ces derniers sont souvent visionnables sur YouTube !) mais bien dans les rencontres fortuites et les échanges informels qui peuvent s’avérer aussi importants que les présentations officielles.
Autre innovation : un "Mentoring Hub" permettant aux participants de s'asseoir à une table de discussion avec un Java Champion pour poser des questions sur comment faire évoluer sa carrière, comment devenir speaker, et bien d'autres sujets.
Ces initiatives de "reconnexion" s'intègrent dans les valeurs fondamentales de nos métiers et de ce genre d'événement : le partage de connaissance.
Le retour du développeur Full-Stack : renaissance ou nostalgie ?
L'une des premières sessions, présentée par Simon Martinelli, abordait un sujet qui fait débat dans la communauté : "Return of the Full-Stack Developer".
Avec un brin de nostalgie, Simon nous a rappelé qu'à l'aube de l'informatique, tous les développeurs étaient par défaut "full-stack". Des programmes COBOL avec des interfaces en mode terminal aux applications Java Swing puis Struts 1, le développeur maîtrisait assez souvent l'ensemble de la chaîne. Les développeurs Javascript, jQuery existaient mais ces derniers s’intéressaient assez peu au backend.
C'est véritablement en 2010, avec l'émergence des frameworks modernes comme Angular et React, que la séparation entre front-end et back-end s'est cristallisée. L’avis de Simon peut être résumé par "Jack of all trades, master of none" (touche-à-tout, expert en rien). Selon lui, il est devenu quasiment impossible d'exceller dans ces deux domaines tant les stacks technologiques ont divergé.
Sa proposition pour redevenir un développeur full-stack pleinement compétent ? Revenir à une stack technologique unique : Java. La démonstration comparative d'applications codées en JTE (Java Template Engine), Primefaces, Qute et Vaadin a illustré cette possibilité de maîtriser l'ensemble du développement sans jongler entre différents langages.
Cette approche soulève néanmoins une question : est-ce un retour aux sources bienvenu ou une résistance au changement ?
OpenTelemetry : quand l'observation devient un super-pouvoir
Si un talk devait être qualifié de "must-see" lors de cette JCON, ce serait certainement celui de Cees Bos sur OpenTelemetry.
Partant du principe que le monitoring en production constitue une source de feedback continu pour améliorer le code, Cees a présenté cet outil de la Linux CNCF (Cloud Native Computing Foundation) de manière concrète et pratique.
L'approche d'OpenTelemetry est non-intrusive : utilisant la notion d'agent de la JVM, il permet d'observer votre code sans aucune modification de ce dernier. Il suffit de renseigner le jar d'OpenTelemetry dans les arguments de la ligne de commande JVM pour commencer à collecter les données exploitables.
Ce qui a particulièrement marqué l'audience, c'est la démonstration de la puissance des traces pour comprendre le comportement réel des applications en production et aide à identifier, parfois préventivement, les problèmes.
Pour pousser l'expérience plus loin, Cees a mis en place un "Application Observability Code Challenge" permettant à chacun de partir de ce projet, de le monitorer et de découvrir ses bottlenecks à corriger.
Je vous invite à vous y confronter ! :D
De ChatGPT à RAG : quand l'IA rencontre Java
L'intelligence artificielle était bien sûr au rendez-vous de cette JCON, avec notamment une session de Pasha Finkelshteyn intitulée "From ChatGPT User to RAG Implementer: A Developer's Journey".
Pasha a partagé son expérience de transition d'un simple utilisateur de ChatGPT à un implémenteur de RAG (Retrieval-Augmented Generation) grâce à Spring AI.
Le pitch initial est simple :
“J’ai trop de documentation, je n’arrive pas à rechercher dedans et trouver une information pertinente”
Partant de ce use case, sa démonstration consiste à indexer toute la documentation pour créer un service capable de répondre précisément à ses questions. Cette approche RAG permet de combiner la puissance des grands modèles de langage avec des connaissances spécifiques à un domaine.
La session a décortiqué le concept de RAG étape par étape : comprendre les embeddings, comment les obtenir et les stocker, et comment les utiliser pour créer un assistant virtuel qui connaît parfaitement votre documentation.
Le tout en Java bien évidemment. 🙂
Modern Java : un AMA révélateur
La session "Ask Me Anything" animée par Ana Maria Mihalceanu et Nicolai Parlog, Developer Advocates chez Oracle, nous a permis d’obtenir des informations de première main sur l'avenir d'OpenJDK.
Les questions ont fusé sur des sujets variés.
L'intégration de Lombok dans Java ?
Pourquoi faire quand Java propose à présent les records depuis Java 17 ?
Comment se fait-il que l’ajout des Virtual Threads (projet Loom) a été rapide alors que le projet Valhalla est lent ?
Parce que l’équipe de développement a reçu énormément de feedback pour le projet Loom ce qui lui a permis d’avancer plus rapidement vers la solution optimale.
Pourquoi ne pas accepter des breaking changes (et par exemple ne plus avoir la suppression des types des génériques à la compilation) ?
Pourquoi devrait-on ? Ils partagent la lettre de Brian Goetz allant en ce sens et rappellent que Java est utilisé par des milliards de terminaux. Un breaking change qui peut paraître négligeable pour l’un ne l’est pas pour toute une autre industrie d’utilisateurs.
Cette session a mis en lumière la tension créative qui existe dans l'écosystème Java : d'un côté, une communauté qui pousse pour l'innovation rapide, et de l'autre, un engagement indéfectible envers la rétrocompatibilité.
L'ingénierie de la productivité au CERN : autonomie et excellence
La présentation de Cristian Schuszter sur "Developer Productivity Engineering at CERN" a été particulièrement inspirante. Elle a montré comment une organisation aussi large et prestigieuse que le CERN met en œuvre des pratiques agiles concrètes pour ses 80 développeurs.
L'autonomie accordée aux développeurs du CERN est un modèle : au minimum un jour sur cinq est "libre". Ils peuvent apprendre une nouvelle technologie même si elle n'est pas utilisée au CERN, contribuer à un projet open source, ou explorer d'autres domaines. La seule contrepartie est qu'ils doivent partager leurs apprentissages avec le reste de l'équipe.
Tout savoir mérite d’être partagé et pourrait contribuer à terme à des décisions techniques futures de manière éclairée.
Face à une cartographie impressionnante de technologies utilisées au CERN depuis plusieurs décennies, l'approche est pragmatique : plutôt que d'avoir un expert par technologie, l'accent est mis sur une documentation efficace, accessible et des bonnes pratiques bien établies. Avec une batterie de tests couvrant les exigences fonctionnelles et les performances, un développeur junior peut contribuer sereinement à une base de code jusque-là inconnue.
La présentation s’est terminée par une démonstration de Develocity, un outil proposé par Gradle en démontrant comment les ingénieurs du CERN gagnent du temps grâce à une mise en cache efficace des builds, même sur un ordinateur qui n'a jamais compilé le projet auparavant.
En contrôlant leur environnement et leur apprentissage,les développeurs au CERN améliorent d’eux-mêmes leurs apprentissages et leurs performances. Un modèle à suivre d’agilité !
Conclusion : Java à 30 ans, entre héritage et renouveau
Cette 10ème édition de JCON, coïncidant avec les 30 ans de Java, a été le reflet parfait de l'état actuel de l'écosystème : un mélange harmonieux de respect pour l'héritage et d'enthousiasme pour l'innovation.
Si Java a été conçu pour permettre aux développeurs “d'écrire une fois et d'exécuter partout" force est de constater que, trente ans plus tard, cette vision s'est élargie : Java permet désormais aux développeurs d'apprendre une fois et d'appliquer partout, que ce soit dans le cloud, l'IA, l'IoT ou les applications d'entreprise traditionnelles.
Bon anniversaire Java !
Et à l’année prochaine. 🙂
La rédaction de cet article a été assistée par une IA.
