LCC 280 - Leçon de géographie

[Emmanuel Bernard]

Cet épisode une fois n'est pas coutume parle beaucoup de nouvelles dans la rubrique langage et beaucoup de Java, wouhou !

On parle aussi de sigstore, http/3, Micronaut et de VMWare.

https://lescastcodeurs.com/2022/06/13/lcc-280-lecon-de-geographie/

Emmanuel

[Remi Forax]

Plein de trucs à dire sur cet épisode.

Donc effectivement, le changement de cadence de Java date de juste après Java 9, Java 10 est la première version avec la nouvelle cadence.

Pour l'avoir vécu de l'intérieur, la gestion de la release de la version 9 a été assez catastrophique, la version 9 devait au départ durée 2 ans, à la fin, cela a durée 3 ans et démi, avec une dernière année où le seul truc qui bloquait c'était les modules. Dès Java 5, y avait eu des discussions pour abandonner les features releases, la version 9 a été ce qui a poussé les derniers réticents vers le systèmes de timeboxed releases.

Le but de Leyden, le but est de voir quels changements ont peut faire dans le langage pour accélérer le démarrage/être plus adapter au monde des conteneurs/VMs, donc cela couvre la création d'image statique (par exemple, répondre à la question: peut-on exécuter un block statique à la compilation) mais aussi l'intégration des technos de checkpointing (le projet openjdk CraC [1]) basé sur Criu  pour linux [2] ou le checkpointing de VMs comme avec firecracker. L'intérêt du checkpointing est que l'on garde un Java dynamique sans la contrainte de monde clos (closed world) que l'on a on avec une image statique.

Et effectivement, espèrons que cela va pas se transformer en bataille entre Oracle et Oracle Labs.

Structured Concurrency: pour l'instant en Java, soit on a des pools de thread + des futures, soit on utilises des apis reactive au dessus des pools de thread + future. Loom rends la création de threads lightweigth pas chère, donc pooler les threads devient inutiles, en même temps, on veut éviter d'aller vers une API full reactive car la gestion propre des exceptions/cancellations avec une API reactive est une horreur. Entre les deux, on pense qu'il peut exister une API basée sur le concept de structured concurrency [3], dans le cas de Java une API basé sur des try-with-resources imbriqués pour indiquer comment des taches s'exécutent en parallèle, se cancel automatiquement en cas d'erreur si nécessaire etc, plus facile à *bien* utiliser qu'une API reactive. Pour l'instant, dans le JDK 19, il y a une proposition d'API dans un module incubator, mais l'API va surement changée (enfin j'espère :), car c'est le premier jet.

ReactNative essaye d'utiliser les composants natifs de la platforme comme AWT/SWT tandis que Flutter dessine la même chose quelque soit la plateforme comme Swing/JavaFX.

Les deux approches, même dessin quelque soit la plateforme ou réutilisation de composants natif de la plateforme existait déjà au temps de SmallTalk.

Pour Skia, c'est le moteur de rendu 2D/3D utilisé par Firefox et Chrome, donc utilisé depuis par Flutter. JetBrain maintient des bindings de skia pour Kotlin et utilise skia dans Fleet.

Rémi

[1] https://foojay.io/today/introducing-the-openjdk-coordinated-restore-at-checkpoint-project/

[2] https://criu.org/Main_Page

[3] https://en.wikipedia.org/wiki/Structured_concurrency

---

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "lescastcodeurs".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse lescastcodeur...@googlegroups.com.
Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/CAEW2RjKFQKrTkvMmgsdAPS1OByHqQHQ98uvt60%2BZCWrbmGoH6Q%40mail.gmail.com.

[Emmanuel Bernard]

Merci Rémi pour ces détails et correctifs.

Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/lescastcodeurs/2016541837.1522939.1655576324660.JavaMail.zimbra%40u-pem.fr.