# JDK 17, et autres nouveautés autour du JDK

par Thomas Broyer

Nous avions couvert la sortie du JDK 11 dans le tout premier BOT, et voilà 3 ans plus tard arriver JDK 17, la nouvelle version LTS du JDK. On rappellera rapidement que la notion de version LTS est totalement dépendante des mainteneurs, et en l’occurrence d’Oracle ; mais de nombreux acteurs (RedHat, Adoptium, Amazon, etc.) se calquent sur Oracle pour le suivi des versions de l’OpenJDK (avec des durées de support plus ou moins longues cependant), quand d’autres fournissent du support étendu également pour d’autres versions (Azul par exemple, avec des versions intermédiaires Medium-Term Support, MTS).

RedHat, qui est intendant pour OpenJDK 8 et OpenJDK 11, assurera de son côté la maintenance jusqu’en 2024 (et même 2026 pour OpenJDK 8), ce qui signifie tout de même qu’il est grand temps de passer à la version 17 pour les nouveaux projets, et de commencer à l’envisager pour les projets en cours !

Alors pour ceux qui, comme beaucoup, utilisent aujourd’hui JDK 11, qu’apporte JDK 17 ?

Nous avions précédemment couvert presque toutes les versions intermédiaires (12, 13, 14 plus ou moins, et 15), mais voici un bref résumé :

  • Les blocs de texte permettent d’avoir des chaînes de caractères multi-lignes sans avoir recours à des séquences d’échappement et/ou de la concaténation
  • Les expressions switch permettent d’utiliser switch…case comme une expression, avec dans le cas des enums une validation à la compilation qu’il ne manque pas une valeur.
  • Le pattern matching avec instanceof simplifie légèrement les tests sur instanceof suivis de conversions, en permettant de faire cette conversion directement dans la condition avec la déclaration d’une nouvelle variable locale.
  • Les sealed classes (ou interfaces) définissent quelles autres classes peuvent les étendre (ou les implémenter) ; ces classes pouvant être dans des packages différents (un cas où les astuces avec un constructeur package-private ne fonctionnent pas).
  • Les records apportent une syntaxe compacte pour définir des value objects immuables, où les méthodes equals(), hashCode() et toString(), entre autres, sont générées automatiquement.
  • Les messages d’erreur des NullPointerException sont bien plus utiles, en pointant la variable (ou l’expression) qui est null, et le champ ou la méthode dont l’accès a généré l’erreur.
  • Toute la pile cryptographique a connue de belles avancées, avec support des signatures EdDSA, des cypher suites ChaCha20 et Poly1305, et une préférence pour la « forward secrecy ».
  • Idem pour l’internationalisation avec des mises à jour Unicode et CLDR.
  • Un nouvel outil jpackage permet de créer facilement des installeurs (Windows ou Mac) ou des paquets natifs (Debian ou RPM) pour ses applications, embarquant directement une JVM (via jlink).

Au chapitre des previews (et qui devront donc attendre la prochaine LTS dans 2 ans avant qu’on puisse les utiliser en production, pour ceux qui ne déploient que des versions LTS), le pattern matching dans les switch supporte des expressions dans les case, et non plus uniquement des constantes.

Et enfin, du côté des suppressions et dépréciations :

  • Le paramètre –illegal-access disparaît, il faudra obligatoirement passer par –add-opens et –add-exports pour les bibliothèques et programmes qui font appel à des classes internes au JDK ou à un module.
  • Après avoir été déprécié dans JDK 15, l’activation RMI est définitivement supprimée.
  • Les APIs Applet et Security Manager sont dépréciées et seront supprimées dans une prochaine version.

Voilà pour le JDK 17, mais ce n’est pas tout !

En ce mois de septembre, Oracle annonce également son intention de passer sur un cycle de 2 ans pour les versions LTS (la prochaine sera donc la version 21).

La politique de licence change aussi radicalement pour l’Oracle JDK, avec un retour, pour les versions LTS uniquement, à une licence gratuite (No-Fee Terms & Conditions) pour tous les usages (y compris en production, comme c’était le cas jusqu’à JDK 8 inclus) pendant 3 ans, suivie d’un support payant avec la licence Oracle Technology Network pendant au moins 5 ans.

# Lit 2.0

par Thomas Broyer

Dans le monde des web components, les bibliothèques lit-html et lit-element, comme Polymer avant elles, sont quasi incontournables. Plus de 3 ans après leur début et 2 ans après leur première version stable, Google avait annoncé en avril dernier une nouvelle version et une nouvelle ligne directrice pour les unifier, sous le nom de Lit 2. Très exactement 5 mois plus tard, ce 21 septembre 2021, la version stable de Lit 2 est arrivée !

Lit est donc une bibliothèque pour créer des web components. Bien que ce ne soit pas strictement nécessaire, comme nous le montre Cory LaViska, ce genre de bibliothèque (tout comme FAST Element de Microsoft ou Stencil de Ionic) prend en charge un grand nombre de détails et subtilités du développement de web components et réduit la quantité de code nécessaire d’autant, pour nous laisser nous concentrer sur le cœur de nos composants.

Il est important de noter (comme le rappelle Cory LaViska) que Lit est une bibliothèque et non un framework : “si vous voulez qu’un composant React fonctionne, vous devez l’utiliser avec React. Si vous voulez qu’un composant Vue fonctionne, vous devez l’utiliser avec Vue. Si vous voulez qu’un composant Angular fonctionne… bref, vous avez compris.” Les web components pourront par contre facilement être utilisés avec n’importe quel framework comme Angular, Preact, Svelte ou Vue (React demandera un peu plus d’efforts, même si les choses commencent à bouger)

Lit est donc plus petit que ses prédécesseurs (lit-html et lit-element), plus rapide aussi, mais apporte pour autant tout un ensemble de nouvelles fonctionnalités comme les element expressions, les reactive controllers ou encore les directives asynchrones.

Et en plus de Lit lui-même, des bibliothèques basées sur ces nouvelles fonctionnalités sont en cours de développement / maturation dans les Lit Labs. On y trouve par exemple un support du rendu côté serveur (SSR, basé sur un standard en cours de développement au W3C) ou encore une bibliothèque d’animation des composants, en moins d’une ligne de code, c’est bluffant.

Et puisqu’on parle web components, Nolan Lawson a fait un benchmark cet été qui montre que l’utilisation du Shadow DOM permet (contrairement à ce que beaucoup redoutaient) d’améliorer la performance du CSS.

# OWASP Top 10 : 2021

par Quentin Aymard

L’OWASP (Open Web Application Security Project) édite régulièrement un rapport faisant référence dans le monde du développement et de la sécurité des applications web, sobrement nommé Top 10. Ce rapport répertorie les 10 principales sources de menaces pour la sécurité des applications web : on ne parle pas ici de vulnérabilités techniques au sens du Common Vulnerabilities and Exposures (CVE) system (cf https://nvd.nist.gov pour plus de détails) mais bien de catégories de problèmes de conception ou de réalisation typiques des applications web, dont l’exploitation a conduit à des incidents par le passé. C’est donc un recueil précieux d’informations pour les développeur·euses d’applications web, une référence à prendre en compte dans tout processus de qualité de code digne de ce nom.

Cette nouvelle mouture 2021 apporte quelques modifications intéressantes, mais nous nous arrêterons en particulier sur l’ajout d’une nouvelle catégorie arrivant directement en quatrième position du Top 10 : Insecure Design ! Si les autres catégories couvrent divers types de réalisations incorrectes ou peu consciencieuse, cette nouvelle catégorie concerne l’ensemble des éléments organisationnels intervenant au cours de la phase de conception d’une nouvelle application.

La sécurité en informatique n’est jamais absolue, il s’agit toujours d’un état souhaité que l’on a établi au regard d’un ensemble de menaces, souvent formulé à l’aide d’une analyse des risques. Cette nouvelle catégorie de l’OWASP permet de décrire toutes les vulnérabilités qui sont issues d’un processus de conception n’ayant pas pris le temps d’identifier lesdites menaces, ni de formaliser les risques encourus par la nouvelle application. L’organisation, n’ayant pas souhaité ou pas sû identifier ces éléments, sera naturellement dans l’incapacité d’y apporter des réponses techniques adéquates.

L’apparition de cette nouvelle catégorie au sein du classement est un nouvel appel lancé à l’industrie en faveur de l’adoption massive d’une méthodologie dite de Security by design (dont on vous parlait il y a quelques mois), dans laquelle les éléments de sécurité ne sont pas considérés comme des fonctionnalités mais comme faisant partie du contrôle qualité. Il y a quelques mois, nous vous parlions de notre nouvelle certification ISO 27001, dont les principes fondamentaux incluent cette notion de Security by design. Le nombre croissant d’entreprises certifiées ainsi que ces nouvelles injonctions dans des organes de référence de l’industrie tendent à démontrer une tendance de fond, en direction d’une production logicielle outillée et rigoureuse dès les premières étapes de la vie du projet, jusqu’à la livraison et au-delà.

# Corepack node module manager manager

par Guillaume Poittevin

Non je n’ai pas fait d’erreur dans le titre ! Le 7 septembre dernier NodeJS a sorti une version mineure, la 16.9.0. En temps normal je ne m’attarderais pas à écrire une note sur une version contenant principalement des petits correctifs. Mais cette version vient avec une fonctionnalité expérimentale qui m’a interpellé : corepack.

Qu’est ce que corepack ? Et bien c’est un outil qui va permettre de gérer les outils de gestion de module. Corepack va pouvoir détecter que votre projet utilise npm, yarn ou pnpm et se chargera de rendre disponible le gestionnaire de paquet adapté pour votre projet.

# Changement de politique tarifaire pour Docker Desktop

par Guillaume Poittevin

Déjà mainte fois évoqué, la difficulté du financement des projets open source, crée régulièrement des changements de politique tarifaire ou des changement de licence. Fin août dernier, c’est Docker qui a mis à jour sa politique liée aux souscriptions.

Si le projet docker (et le projet moby) restent 100% open-souce et disponible gratuitement, il y’a un changement majeur sur l’utilisation de Docker Desktop, ce dernier nécessite une souscription. La souscription «Personnal», qui remplace la souscription «Free», est toujours disponible pour les petites entreprises (moins de 250 salariés et moins de 10M$ de chiffre d’affaires annuel), mais également pour l’éducation et les projets open source non-commerciaux. Si vous ne rentrez pas dans ces critères il faudra passer à une souscription supérieure (qui débute à 5$ / mois / utilisateur). 

Un changement qui risque d’avoir des conséquences dans pas mal de structures, mais des alternatives existent. Il est par exemple possible d’installer docker sans Docker Desktop sous Windows en passant par le WSL2, la procédure est encore un peu complexe, mais gageons que la situation va évoluer vers plus de simplicité suite à ce changement.