LCC 322 - Maaaaveeeeen 4 ! | Les Cast Codeurs Podcast

Arnaud et Emmanuel discutent des nouvelles de ce mois. On y parle intégrité de JVM, fetch size de JDBC, MCP, de prompt engineering, de DeepSeek bien sûr mais aussi de Maven 4 et des proxy de répository Maven. Et d’autres choses encore, bonne lecture.

Enregistré le 7 février 2025

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

News

Langages

Les evolutions de la JVM pour augmenter l’intégrité https://inside.java/2025/01/03/evolving-default-integrity/

un article sur les raisons pour lesquelles les editeurs de frameworks et les utilisateurs s’arrachent les cheveux et vont continuer
garantir l’integrite du code et des données en enlevant des APIs existantes historiquemnt
agents dynamiques, setAccessible, Unsafe, JNI
Article expliques les risques percus par les mainteneurs de la JVM
Franchement c’est un peu leg sur les causes l’article, auto propagande

JavaScript Temporal, enfin une API propre et moderne pour gérer les dates en JS https://developer.mozilla.org/en-US/blog/javascript-temporal-is-coming/

JavaScript Temporal est un nouvel objet conçu pour remplacer l’objet Date, qui présente des défauts.
Il résout des problèmes tels que le manque de prise en charge des fuseaux horaires et la mutabilité.
Temporal introduit des concepts tels que les instants, les heures civiles et les durées.
Il fournit des classes pour gérer diverses représentations de date/heure, y compris celles qui tiennent compte du fuseau horaire et celles qui n’en tiennent pas compte.
Temporal simplifie l’utilisation de différents calendriers (par exemple, chinois, hébreu).
Il comprend des méthodes pour les comparaisons, les conversions et le formatage des dates et des heures.
La prise en charge par les navigateurs est expérimentale, Firefox Nightly ayant l’implémentation la plus aboutie.
Un polyfill est disponible pour essayer Temporal dans n’importe quel navigateur.

Librairies

Un article sur les fetch size du JDBC et les impacts sur vos applications https://in.relation.to/2025/01/24/jdbc-fetch-size/

qui connait la valeur fetch size par default de son driver?
en fonction de vos use cases, ca peut etre devastateur
exemple d’une appli qui retourne 12 lignes et un fetch size de oracle a 10, 2 a/r pour rien
et si c’est 50 lignres retournées
la base de donnée est le facteur limitant, pas Java
donc monter sont fetch size est avantageux, on utilise la memoire de Java pour eviter la latence

Quarkus annouce les MCP servers project pour collecter les servier MCP en Java https://quarkus.io/blog/introducing-mcp-servers/

MCP d’Anthropic
introspecteur de bases JDBC
lecteur de filke system
Dessine en Java FX
demarrables facilement avec jbang
et testes avec claude desktop, goose et mcp-cli
permet d’utliser le pouvoir des librarires Java de votre IA
d’ailleurs Spring a la version 0.6 de leur support MCP https://spring.io/blog/2025/01/23/spring-ai-mcp-0

Infrastructure

Apache Flink sur Kibernetes https://www.decodable.co/blog/get-running-with-apache-flink-on-kubernetes-2

un article tres complet ejn deux parties sur l’installation de Flink sur Kubernetes
installation, setup
mais aussi le checkpointing, la HA, l’observablité

Data et Intelligence Artificielle

10 techniques de prompt engineering https://medium.com/google-cloud/10-prompt-engineering-techniques-every-beginner-should-know-bf6c195916c7

Si vous voulez aller plus loin, l’article référence un très bon livre blanc sur le prompt engineering https://www.kaggle.com/whitepaper-prompt-engineering
Les techniques évoquées :
1. Zero-Shot Prompting:
  - On demande directement à l’IA de répondre à une question sans lui fournir d’exemple préalable. C’est comme si on posait une question à une personne sans lui donner de contexte.
2. Few-Shot Prompting:
  - On donne à l’IA un ou plusieurs exemples de la tâche qu’on souhaite qu’elle accomplisse. C’est comme montrer à quelqu’un comment faire quelque chose avant de lui demander de le faire.
3. System Prompting:
  - On définit le contexte général et le but de la tâche pour l’IA. C’est comme donner à l’IA des instructions générales sur ce qu’elle doit faire.
4. Role Prompting:
  - On attribue un rôle spécifique à l’IA (enseignant, journaliste, etc.). C’est comme demander à quelqu’un de jouer un rôle spécifique.
5. Contextual Prompting:
  - On fournit des informations supplémentaires ou un contexte pour la tâche. C’est comme donner à quelqu’un toutes les informations nécessaires pour répondre à une question.
6. Step-Back Prompting:
  - On pose d’abord une question générale, puis on utilise la réponse pour poser une question plus spécifique. C’est comme poser une question ouverte avant de poser une question plus fermée.
7. Chain-of-Thought Prompting:
  - On demande à l’IA de montrer étape par étape comment elle arrive à sa conclusion. C’est comme demander à quelqu’un d’expliquer son raisonnement.
8. Self-Consistency Prompting:
  - On pose plusieurs fois la même question à l’IA et on compare les réponses pour trouver la plus cohérente. C’est comme vérifier une réponse en la posant sous différentes formes.
9. Tree-of-Thoughts Prompting:
  - On permet à l’IA d’explorer plusieurs chemins de raisonnement en même temps. C’est comme considérer toutes les options possibles avant de prendre une décision.
10. ReAct Prompting:
  - On permet à l’IA d’interagir avec des outils externes pour résoudre des problèmes complexes. C’est comme donner à quelqu’un les outils nécessaires pour résoudre un problème.

Les patterns GenAI the thoughtworks https://martinfowler.com/articles/gen-ai-patterns/

tres introductif et pre RAG
le direct prompt qui est un appel direct au LLM: limitations de connaissance et de controle de l’experience
eval: evaluer la sortie d’un LLM avec plusieurs techniques mais fondamentalement une fonction qui prend la demande, la reponse et donc un score numerique
evaluation via un LLM (le meme ou un autre), ou evaluation humaine
tourner les evaluations a partir de la chaine de build amis aussi en live vu que les LLMs puvent evoluer.
Decrit les embedding notament d’image amis aussi de texte avec la notion de contexte

DeepSeek et la fin de la domination de NVidia https://youtubetranscriptoptimizer.com/blog/05_the_short_case_for_nvda

un article sur les raisons pour lesquelles NVIDIA va se faire cahllengert sur ses marges
90% de marge quand meme parce que les plus gros GPU et CUDA qui est proprio
mais des approches ardware alternatives existent qui sont plus efficientes (TPU et gros waffle)
Google, MS et d’autres construisent leurs GPU alternatifs
CUDA devient de moins en moins le linga franca avec l’investissement sur des langages intermediares alternatifs par Apple, Google OpenAI etc
L’article parle de DeepSkeek qui est venu mettre une baffe dans le monde des LLMs
Ils ont construit un competiteur a gpt4o et o1 avec 5M de dollars et des capacites de raisonnements impressionnant
la cles c’etait beaucoup de trick d’optimisation mais le plus gros est d’avoir des poids de neurores sur 8 bits vs 32 pour les autres.
et donc de quatizer au fil de l’eau et au moment de l’entrainement
beaucoup de reinforcemnt learning innovatifs aussi
et des Mixture of Expert
donc ~50x moins chers que OpenAI
Donc plus besoin de GPU qui on des tonnes de vRAM
ah et DeepSeek est open source
un article de semianalytics change un peu le narratif
le papier de DeepSkeek en dit long via ses omissions
par ensemple les 6M c’est juste l’inference en GPU, pas les couts de recherches et divers trials et erreurs
en comparaison Claude Sonnet a coute 10M en infererence
DeepSeek a beaucoup de CPU pre ban et ceratins post bans evalués a 5 Milliards en investissement.
leurs avancées et leur ouverture reste extremement interessante

Une intro à Apache Iceberg http://blog.ippon.fr/2025/01/17/la-revolution-des-donnees-lavenement-des-lakehouses-avec-apache-iceberg/

issue des limites du data lake. non structuré et des Data Warehouses aux limites en diversite de données et de volume
entrent les lakehouse
Et particulierement Apache Iceberg issue de Netflix
gestion de schema mais flexible
notion de copy en write vs merge on read en fonction de besoins
garantie atomicite, coherence, isoliation et durabilite
notion de time travel et rollback
partitions cachées (qui abstraient la partition et ses transfos) et evolution de partitions
compatbile avec les moteurs de calcul comme spark, trino, flink etc
explique la structure des metadonnées et des données

Guillaume s’amuse à générer des histoires courtes de Science-Fiction en programmant des Agents IA avec LangChain4j et aussi avec des workflows https://glaforge.dev/posts/2025/01/27/an-ai-agent-to-generate-short-scifi-stories/ https://glaforge.dev/posts/2025/01/31/a-genai-agent-with-a-real-workflow/

Création d’un générateur automatisé de nouvelles de science-fiction à l’aide de Gemini et Imagen en Java, LangChain4j, sur Google Cloud.
Le système génère chaque nuit des histoires, complétées par des illustrations créées par le modèle Imagen 3, et les publie sur un site Web.
Une étape d’auto-réflexion utilise Gemini pour sélectionner la meilleure image pour chaque chapitre.
L’agent utilise un workflow explicite, drivé par le code Java, où les étapes sont prédéfinies dans le code, plutôt que de s’appuyer sur une planification basée sur LLM.
Le code est disponible sur GitHub et l’application est déployée sur Google Cloud.
L’article oppose les agents de workflow explicites aux agents autonomes, en soulignant les compromis de chaque approche. Car parfois, les Agent IA autonomes qui gèrent leur propre planning hallucinent un peu trop et n’établissent pas un plan correctement, ou ne le suive pas comme il faut, voire hallucine des “function call”.
Le projet utilise Cloud Build, le Cloud Run jobs, Cloud Scheduler, Firestore comme base de données, et Firebase pour le déploiement et l’automatisation du frontend.
Dans le deuxième article, L’approche est différente, Guillaume utilise un outil de Workflow, plutôt que de diriger le planning avec du code Java.
L’approche impérative utilise du code Java explicite pour orchestrer le workflow, offrant ainsi un contrôle et une parallélisation précis.
L’approche déclarative utilise un fichier YAML pour définir le workflow, en spécifiant les étapes, les entrées, les sorties et l’ordre d’exécution.
Le workflow comprend les étapes permettant de générer une histoire avec Gemini 2, de créer une invite d’image, de générer des images avec Imagen 3 et d’enregistrer le résultat dans Cloud Firestore (base de donnée NoSQL).
Les principaux avantages de l’approche impérative sont un contrôle précis, une parallélisation explicite et des outils de programmation familiers.
- Les principaux avantages de l’approche déclarative sont des définitions de workflow peut-être plus faciles à comprendre (même si c’est un YAML, berk !) la visualisation, l’évolutivité et une maintenance simplifiée (on peut juste changer le YAML dans la console, comme au bon vieux temps du PHP en prod).
Les inconvénients de l’approche impérative incluent le besoin de connaissances en programmation, les défis potentiels en matière de maintenance et la gestion des conteneurs.
Les inconvénients de l’approche déclarative incluent une création YAML pénible, un contrôle de parallélisation limité, l’absence d’émulateur local et un débogage moins intuitif.
Le choix entre les approches dépend des exigences du projet, la déclarative étant adaptée aux workflows plus simples.
L’article conclut que la planification déclarative peut aider les agents IA à rester concentrés et prévisibles.

Outillage

Vulnérabilité des proxy Maven https://github.blog/security/vulnerability-research/attacks-on-maven-proxy-repositories/

Quelque soit le langage, la techno, il est hautement conseillé de mettre en place des gestionnaires de repositories en tant que proxy pour mieux contrôler les dépendances qui contribuent à la création de vos produits
Michael Stepankin de l’équipe GitHub Security Lab a cherché a savoir si ces derniers ne sont pas aussi sources de vulnérabilité en étudiant quelques CVEs sur des produits comme JFrog Artifactory, Sonatype Nexus, et Reposilite
Certaines failles viennent de la UI des produits qui permettent d’afficher les artifacts (ex: mettez un JS dans un fichier POM) et même de naviguer dedans (ex: voir le contenu d’un jar / zip et on exploite l’API pour lire, voir modifier des fichiers du serveur en dehors des archives)
Les artifacts peuvent aussi être compromis en jouant sur les paramètres propriétaires des URLs ou en jouant sur le nomage avec les encodings.
Bref, rien n’est simple ni niveau. Tout système rajoute de la compléxité et il est important de les tenir à mettre à jour. Il faut surveiller activement sa chaine de distribution via différents moyens et ne pas tout miser sur le repository manager.
L’auteur a fait une présentation sur le sujet : https://www.youtube.com/watch?v=0Z_QXtk0Z54

Apache Maven 4… Bientôt, c’est promis …. qu’est ce qu’il y aura dedans ? https://gnodet.github.io/maven4-presentation/

Et aussi https://github.com/Bukama/MavenStuff/blob/main/Maven4/whatsnewinmaven4.md
Apache Maven 4
- Doucement mais surement …. c’est le principe d’un projet
- Maven 4.0.0-rc-2 est dispo (Dec 2024).
- Maven a plus de 20 ans et est largement utilisé dans l’écosystème Java.
- La compatibilité ascendante a toujours été une priorité, mais elle a limité la flexibilité.
- Maven 4 introduit des changements significatifs, notamment un nouveau schéma de construction et des améliorations du code.
Changements du POM
- Séparation du Build-POM et du Consumer-POM :
  - Build-POM : Contient des informations propres à la construction (ex. plugins, configurations).
  - Consumer-POM : Contient uniquement les informations nécessaires aux consommateurs d’artefacts (ex. dépendances).
- Nouveau Modèle Version 4.1.0 :
  - Utilisé uniquement pour le Build-POM, alors que le Consumer-POM reste en 4.0.0 pour la compatibilité.
  - Introduit de nouveaux éléments et en marque certains comme obsolètes.
- Modules renommés en sous-projets :
  - “Modules” devient “Sous-projets” pour éviter la confusion avec les Modules Java.
  - L’élément <subprojects> remplace <modules> (qui reste pris en charge).
- Nouveau type de packaging : “bom” (Bill of Materials) :
  - Différencie les POMs parents et les BOMs de gestion des dépendances.
  - Prend en charge les exclusions et les imports basés sur les classifiers.
- Déclaration explicite du répertoire racine :
  - <project root="true"> permet de définir explicitement le répertoire racine du projet.
  - Élimine toute ambiguïté sur la localisation des racines de projet.
- Nouvelles variables de répertoire :
  - ${project.rootDirectory}, ${session.topDirectory} et ${session.rootDirectory} pour une meilleure gestion des chemins.
  - Remplace les anciennes solutions non officielles et variables internes obsolètes.
- Prise en charge de syntaxes alternatives pour le POM
  - Introduction de ModelParser SPI permettant des syntaxes alternatives pour le POM.
  - Apache Maven Hocon Extension est un exemple précoce de cette fonctionnalité.
Améliorations pour les sous-projets
- Versioning automatique des parents
  - Il n’est plus nécessaire de définir la version des parents dans chaque sous-projet.
  - Fonctionne avec le modèle de version 4.1.0 et s’étend aux dépendances internes au projet.
- Support complet des variables compatibles CI
  - Le Flatten Maven Plugin n’est plus requis.
  - Prend en charge les variables comme ${revision} pour le versioning.
  - Peut être défini via maven.config ou la ligne de commande (mvn verify -Drevision=4.0.1).
- Améliorations et corrections du Reactor
  - Correction de bug : Gestion améliorée de --also-make lors de la reprise des builds.
  - Nouvelle option --resume (-r) pour redémarrer à partir du dernier sous-projet en échec.
  - Les sous-projets déjà construits avec succès sont ignorés lors de la reprise.
  - Constructions sensibles aux sous-dossiers : Possibilité d’exécuter des outils sur des sous-projets sélectionnés uniquement.
  - Recommandation : Utiliser mvn verify plutôt que mvn clean install.
- Autres Améliorations
  - Timestamps cohérents pour tous les sous-projets dans les archives packagées.
  - Déploiement amélioré : Le déploiement ne se produit que si tous les sous-projets sont construits avec succès.
Changements de workflow, cycle de vie et exécution
- Java 17 requis pour exécuter Maven
  - Java 17 est le JDK minimum requis pour exécuter Maven 4.
  - Les anciennes versions de Java peuvent toujours être ciblées pour la compilation via Maven Toolchains.
  - Java 17 a été préféré à Java 21 en raison d’un support à long terme plus étendu.
- Mise à jour des plugins et maintenance des applications
  - Suppression des fonctionnalités obsolètes (ex. Plexus Containers, expressions ${pom.}).
  - Mise à jour du Super POM, modifiant les versions par défaut des plugins.
  - Les builds peuvent se comporter différemment ; définissez des versions fixes des plugins pour éviter les changements inattendus.
  - Maven 4 affiche un avertissement si des versions par défaut sont utilisées.
- Nouveau paramètre “Fail on Severity”
  - Le build peut échouer si des messages de log atteignent un niveau de gravité spécifique (ex. WARN).
  - Utilisable via --fail-on-severity WARN ou -fos WARN.
- Maven Shell (mvnsh)
  - Chaque exécution de mvn nécessitait auparavant un redémarrage complet de Java/Maven.
  - Maven 4 introduit Maven Shell (mvnsh), qui maintient un processus Maven résident unique ouvert pour plusieurs commandes.
  - Améliore la performance et réduit les temps de build.
  - Alternative : Utilisez Maven Daemon (mvnd), qui gère un pool de processus Maven résidents.

Architecture

Un article sur les feature flags avec Unleash https://feeds.feedblitz.com/~/911939960/0/baeldung~Implement-Feature-Flags-in-Java-With-Unleash

Pour A/B testing et des cycles de développements plus rapides pour « tester en prod »
Montre comment tourner sous docker unleash
Et ajouter la librairie a du code java pour tester un feature flag

Sécurité

Keycloak 26.1 https://www.keycloak.org/2025/01/keycloak-2610-released.html

detection des noeuds via la proble base de donnée aulieu echange reseau
virtual threads pour infinispan et jgroups
opentelemetry tracing supporté
et plein de fonctionalités de sécurité

Loi, société et organisation

Les grands morceaux du coût et revenus d’une conférence. Ici <http://bdx.io

bdx.io> https://bsky.app/profile/ameliebenoit33.bsky.social/post/3lgzslhedzk2a

44% le billet
52% les sponsors
38% loc du lieu
29% traiteur et café
12% standiste
5% frais speaker (donc pas tous)

Ask Me Anything

Julien de Provin: J’aime beaucoup le mode “continuous testing” de Quarkus, et je me demandais s’il existait une alternative en dehors de Quarkus, ou à défaut, des ressources sur son fonctionnement ? J’aimerais beaucoup avoir un outil agnostique utilisable sur les projets non-Quarkus sur lesquels j’intervient, quitte à y metttre un peu d’huile de coude (ou de phalange pour le coup).