Dans cet épisode, Emmanuel, Guillaume et Katia abordent les nouveautés Java, le lancement du langage Misty par Douglas Crockford, l’arrivée de WasmGC dans Chrome, la sortie de Spring Framework 6.1, des évolutions dans les bibliothèques comme Vert.x 4.5, et des conseils sur la création de langages de programmation. L’épisode couvre également des actualités dans les domaines de l’infrastructure avec le premier ordinateur cloud commercial par Oxide, des annonces sur les frameworks web comme Angular v17, des réflexions sur les architectures monolithiques versus microservices, et sans oublier le soap Opéra du moins de novembre avec OpenAI en vedette. Enregistré le 23 novembre 2023 Téléchargement de l’épisode LesCastCodeurs-Episode-302.mp3 News Langages Recap Javaiste https://www.infoq.com/news/2023/10/java-news-roundup-oct09-2023 la JEP 454 sur l’appel a la memoire et les API dites natives passera en target pour JDK 22 avec une façon d’ajouter les appels de méthodes restreintes sans le flag --enable-native-access (via un manifeste dans le JAR) JDK 22 prévu pour mars 2024 Spring Framework 6.1 est sorti (RC2) Tomcat a quelques CVE donc mettez à jour Douglas Crockford, le papa de JSON, sort un nouveau langage dénommé Misty https://www.crockford.com/misty/ Utilise des caractères unicodes pour définir des chaînes de caractères avec des chevrons, ou pour les opérateurs de base (comparison, and/or) Support de programmation concurrente avec les actors WasmGC arrive dans Chrome, par l’intermédiaire de v8 https://v8.dev/blog/wasm-gc-porting historiquement il fallait compiler le port du langage lui meme (et donc son GC) Maintenant on peut compiler le code (java) dans des primitives Wasm et WasmGC Java python et co ont des VM qui sont compilées pour toutes les architecture cibles (ARM, x86 etc) y compris le JIT, AOT donc on peut définir comme backend WASM lui meme, c’est l’approche classique WasmGC définit des structs et des array avec des champs dans lesquels on peut créer des instances, lire/écrire les champs, caster dans d’autres types et ces objects sont managés par WasmGC lui meme. on a un système de type du coup et des relations entre ces types Donc on représenterait les objets Java en objets Wasm avantage et inconvenient des deux approches tous les codes de management d’objets ne sont plus nécessaires (y compris malloc) -> gain memoire en mode GC dans le langage les liens object langage objets Wasm sont inefficaces car le lien langage -> wasm définissent l’instance entière Wasm, donc des gros cycles d’objets ne sont pas GCed Wasm sandbox empêche d’inspecter la stack et d’éliminer des objets plus efficacement, et il n’y a pas d’API pour aider donc seul WasmGC peut utiliser cet avantage. un seul GC a des avantages: meilleure gestion de la pression memoire mais on réutilise le GC du web (genre V8) vs celui de Java. (c’est moins un problème pour les autres langages avec des gc moins sophistiqués) fragmentation memoire, est plus proéminent quand on a des modules de type C qui peur garder des gros blocs memoire “quasi vide” (opaque). c’est managé plus finement en WasmGC Sémantiques de langage est plus dur a achevé vu qu’on map en concepts WasmGC, il y a de la transformation. sémantiques chaine de caractère, nombres, etc peuvent être un peu ajusté un port utilisant WasmGC n’est pas une réécriture de tout mais un gros morceau de la VM du langage cible est a réécrire WasmGC peut optimiser comme les patterns en JVM mais en WasmMVP c’est la toolchain avant qui fait le travail d’optimisation (e.g. LLVM) donc avec WasmGC, la toolchain fera les optimisations de langage et WasmGC fera les optimisations low level (inlining, constant propagation, dead code elimination) puis d’autres optimisation specific a WasmGC comme les escape analysis, et ils parlent d’optimisations dans V8 pour approcher les appels dynamique a la Java (pas d