LCC 340 - Episode on l'voit on l'voit pas

Java 26 est là, GraalVM cartonne chez Trivago (43 à 12 réplicas !), OpenJDK interdit le code généré par LLM, Spring et Quarkus enchaînent les releases. Côté IA : ADK 1.0, A2A, Lyria 3 chante (mal ?), Yann LeCun lance Ami Labs et ses World Models. Mythos d'Anthropic fait trembler la sécu, Claude Code a leaké son source, et les git worktrees envahissent vos terminaux. Bonus : la mort annoncée de l'IDE, vagues de licenciement chez Oracle et Block, et nos voix toutes clonées. Bon week-ends de mai !

Enregistré le 7 mai 2026

Téléchargement de l'épisode LesCastCodeurs-Episode-340.mp3 ou en vidéo sur YouTube.

News Langages Retour d'expérience d'une migration vers graalVM chez Trivago https://medium.com/graalvm/inside-trivagos-graalvm-migration-native-image-for-graphql-at-scale-912bca9df841

La passerelle GraphQL de Trivago (point d'entrée de tout le trafic vers 48 microservices) souffrait de pics de timeout au démarrage JVM Résultats spectaculaires après migration vers GraalVM Native Image : réduction des réplicas de 43 à 12, CPU de 15 à 5 cœurs, images Docker plus légères Obstacles techniques : incompatibilité Log4j → migration vers Logback, remplacement de Mockk par Testcontainers, compilation CI/CD très gourmande Netflix DGS et d'autres librairies manquaient de support GraalVM → l'équipe a contribué des correctifs upstream en open source Approche recommandée : commencer par les services les moins complexes, investir massivement dans les tests automatisés À la 14e migration, le processus était si rodé qu'il allait plus vite que la toute première tentative OpenJDK Interim Policy on Generative AI - https://openjdk.org/legal/ai

OpenJDK adopte une politique intérimaire interdisant toute contribution incluant du contenu généré par des LLMs, modèles de diffusion ou systèmes deep-learning Le périmètre est large : code source, texte, images dans les dépôts Git, pull requests GitHub, emails, pages wiki et issues JBS Les contributeurs peuvent utiliser les outils d'IA de manière privée pour comprendre, déboguer et relire le code OpenJDK, mais ne peuvent pas contribuer le contenu généré Trois risques justifient cette politique : surcharge des relecteurs face au code plausible mais incorrect, risques de sûreté/sécurité pour une plateforme critique, et risques de propriété intellectuelle (l'OCA exige que les contributeurs possèdent les droits IP de leurs contributions) Même éditer partiellement du code AI-généré ne le rend pas acceptable à la contribution Oracle, sponsor corporatif d'OpenJDK, travaille sur une politique complète à soumettre au Governing Board GraalVM Native Image et la Closed-World Assumption en Java https://pvs-studio.com/en/blog/posts/java/1357/

Un bon article de rappel du contexte de closed world en Java GraalVM Native Image compile les applications Java en exécutables natifs statiques, sans JVM au runtime. La JVM fonctionne en monde ouvert : les classes sont chargées à la demande, les appels sont des références symboliques résolues dynamiquement. Native Image impose la "closed-world assumption" : tous les chemins d'exécution doivent être connus à la compilation. Les fonctionnalités dynamiques Java (réflexion, proxies, chargement de classes) créent des chemins cachés invisibles à l'analyse statique. C'est pourquoi Native Image exige des fichiers de configuration explicites pour la réflexion, les proxies, les ressources et la FFM API. L'article illustre le problème avec la Foreign Function & Memory API pour appeler printf natif : fonctionne sur JVM, échoue en Native Image sans config. Inclure tout le bytecode accessible serait inutilisable : binaire géant, compilation très lente, et la réflexion nécessite des métadonnées précises. La configuration n'est pas un défaut de conception mais une conséquence logique du passage du dynamique au statique. Java 26 : les nouveautés https://foojay.io/today/java-26-whats-new/

Java est le langage de la JVM, publié tous les 6 mois depuis Java 9 ; Java 26 est une version non-LTS avec 10 J