URL: https://linuxfr.org/news/java-15-est-sorti Title: Java 15 est sorti Authors: barmic 🩩 bobble bubble, NonolapĂ©ro, Yves Bourguignon, Lawless, BenoĂźt Sibaud, BAud, Davy Defaud, theojouedubanjo et Ysabeau đŸ§¶ Date: 2020ćčŽ09月04æ—„T13:08:31+02:00 License: CC By-SA Tags: java Score: 55 Ce 15 septembre 2020 sort Java 15. C’est l’occasion pour cette dĂ©pĂȘche de revenir sur les nouveautĂ©s entre les blocs de texte et autres ramasse‐miettes. On en profite pour parler de quelques informations autour de Java (les vingt‐cinq ans de la plate‐forme, les nouveaux champions, etc). ---- [OpenJDK 15](https://openjdk.java.net/projects/jdk/15/) [Quarkus 1.5](https://quarkus.io/blog/quarkus-1-5-final-released/) ---- # Java 15 ## Abandons Avec ce nouveau rythme, Java s’autorise Ă  supprimer des parties de la plate‐forme. Pour cette version : - le systĂšme d’exploitation [Solaris](https://fr.wikipedia.org/wiki/Solaris_(syst%C3%A8me_d%27exploitation)) et l’architecture [SPARC](https://fr.wikipedia.org/wiki/Architecture_SPARC), [rendus obsolĂštes par la derniĂšre version](https://linuxfr.org/news/java-14-tombe-le-masque#toc-les-mises-au-placard-et-lesd%C3%A9parts), ne sont plus pris en charge ([JEP 381](https://openjdk.java.net/jeps/381)) — cocasse quand on connaĂźt les dĂ©buts du langage ; - [Nashorn](https://fr.wikipedia.org/wiki/Nashorn_(moteur_JavaScript)), le moteur JavaScript inclus dans le JDK, a lui aussi Ă©tĂ© retirĂ© ([JEP 372](https://openjdk.java.net/jeps/372)), il Ă©tait considĂ©rĂ© comme obsolĂšte depuis la version 11 sortie en septembre 2018 ; - ce n’est pas encore une suppression, mais RMI activation (et seulement RMI activation pas tout RMI) est rendu obsolĂšte ([JEP 385](https://openjdk.java.net/jeps/385)) ; - _biased locking_ n’est plus activĂ© par dĂ©faut (il faut ajouter l’option `-XX:+UseBiasedLocking`), elle est du mĂȘme coup considĂ©rĂ©e obsolĂšte ([JEP 374](https://openjdk.java.net/jeps/374)). ### ConsĂ©quences des retraits #### Cas de la prise en charge SPARC/SOLARIS Le JDK Ă©tant plutĂŽt vaste, le retrait de la prise en charge d’une architecture a des consĂ©quences Ă  de trĂšs nombreux endroits allant des systĂšmes de construction, la sĂ©curitĂ©, la gĂ©nĂ©ration du _bytecode_ ou encore la gĂ©nĂ©ration d’[IHM](https://fr.wikipedia.org/wiki/Interactions_homme-machine "interfaces homme‐machine"). La personne en charge de la JEP a donc fait le tour du propriĂ©taire pour retirer tout ce qui devait l’ĂȘtre, comme on peut le voir sur [la liste de diffusion](https://mail.openjdk.java.net/pipermail/jdk-dev/2020-May/004292.html). Les plus curieux pourront suivre les diffĂ©rents liens pour voir le mode de dĂ©veloppement du JDK et les spĂ©cificitĂ©s de chaque domaine. Au final, ce sont plus de 127 000 lignes qui ont Ă©tĂ© supprimĂ©es, ce qui ne reprĂ©sente que moins d’un pourcent du nombre total de lignes de code. #### Cas de la gestion du JSON Suite Ă  la suppression du Nashorn JavaScript Engine, il est apparu que le JDK utilisait le JavaScript et par consĂ©quent le JSON pour certaines fonctionnalitĂ©s. Se pose alors la question d’une gestion native du JSON ou de laisser cette compĂ©tence Ă  des bibliothĂšques tierces. Actuellement, rien n’est dĂ©cidĂ© et il y a deux directions possibles : + oui, mais sous quelle forme et quand ? + non pas pour Ă©viter d’avoir quelque chose de mal foutu comme pour le XML ou encore le journalisation et se concentrer sur ce qui fait rĂ©ellement la plus‐value du JDK. ## NouveautĂ©s ### Ramasse‐miettes Deux nouveaux [ramasse‐miettes](https://fr.wikipedia.org/wiki/Ramasse-miettes_(informatique)) (_garbage collectors_ — gc) sont disponibles en stable avec cette version : #### Shenandoah Shenandoah est un ramasse‐miettes qui vise Ă  rĂ©duire les temps de pause. Pour atteindre cet objectif, il dĂ©place les objets sans avoir Ă  mettre en pause l’application. Il est aussi capable de mieux parallĂ©liser le dĂ©placement d’objet. Cela ne supprime pas totalement les pauses : elles sont encore nĂ©cessaires pour libĂ©rer la mĂ©moire. Avec Shenandoah, la vĂ©rification des objets en vie et leur dĂ©placement se fait sans pause, mais le nettoyage de la mĂ©moire en rĂ©clame une. Comme il fait moins de choses pendant les pauses, elles sont plus courtes. L’activation se fait via l’option `-XX:+UseShenandoahGC`. Ce changement est dĂ©crit dans la [JEP 379](https://openjdk.java.net/jeps/379). #### ZGC ZGC se donne pour objectif d’avoir des temps de pause faibles, y compris sur de grands tas (_heap_) de l’ordre du tĂ©raoctet. Pour cela, il est capable de dĂ©charger les classes sans arrĂȘter l’exĂ©cution. Tous les ramasse‐miettes actuels de Java effectuent du dĂ©chargement de classes, mais ils sont obligĂ©s de le faire uniquement durant le _stop the world_. ZGC a travaillĂ© pour pouvoir faire cela en concurrence de l’application. Il semble que cela a eu des effets de bord positifs, notamment le temps de pause n’est dĂ©pendant que du nombre de fils d’exĂ©cution de l’application. Il s’agit de l’amĂ©lioration majeure, mais il y a eu bien d’autres travaux comme le fait de pouvoir rendre de la mĂ©moire au systĂšme d’exploitation, la gestion de tas de 8 Mio jusqu’à 16 Tio. Actuellement, seuls Windows, macOS et GNU/Linux sur les architectures x86-64 et AArch64 sont pris en charge. Pour l’activer, c’est l’option `-XX:+UseZGC`. Ce changement est dĂ©crit dans la [JEP 377](https://openjdk.java.net/jeps/377).> _C’est trĂšs bien mais, du coup, comment choisir entre Shenandoah, ZGC ou rester sur G1 ?_ C’est une question bien complexe qui est Ă©videmment trĂšs dĂ©pendante de l’application cible. PremiĂšrement, G1, malgrĂ© le fait qu’il continue d’ĂȘtre amĂ©liorĂ©, est trĂšs loin derriĂšre ZGC et Shenandoah. Les objectifs de ces derniers sont assez similaires et ils sont tellement efficaces qu’on ne peut pas voir de diffĂ©rence entre eux quand ils sont comparĂ©s Ă  G1... De mon avis personnel et de ce que j’en ai lu : - ZGC est fait pour ĂȘtre simple, il est moins configurable ; - Shenandoah est plus configurable et il offre des temps de pause plus prĂ©dictibles que ZGC. NĂ©anmoins, tout cela peut encore changer d’ici la sortie de Java 17 (en septembre 2021). ### Blocs de texte Les blocs de texte arrivent enfin en version dĂ©finitive ([JEP 378](https://openjdk.java.net/jeps/378)). Cette fonctionnalitĂ© a fait beaucoup parler d’elle depuis son introduction en Java 13. Il est donc maintenant possible de dĂ©finir des chaĂźnes de caractĂšres multilignes comme ça : ```java String query = """ SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB" WHERE "CITY" = 'INDIANAPOLIS' ORDER BY "EMP_ID", "LAST_NAME"; """; ``` ### Classes cachĂ©es Cette nouveautĂ© offre la possibilitĂ© aux cadriciels de gĂ©nĂ©rer des classes pour son propre usage qui ne seront pas accessibles de l’extĂ©rieur et ainsi de gĂ©rer la tambouille interne sans risque de fuite, notamment en utilisant la rĂ©flexion. Java possĂšde des classes internes, qui ne sont pas directement exposĂ©es au niveau de l’API, mais qui restent accessibles par rĂ©flexion. Ce n’est pas leur nom peu allĂ©chant `Unsafe` qui empĂȘche qu’elles soient largement utilisĂ©es par tout un tas de logiciels. Un des objectifs des dĂ©veloppeurs du JDK est de faire en sorte que cette pratique cesse. Un [article de _Java Magazine_](https://blogs.oracle.com/javamagazine/the-unsafe-class-unsafe-at-any-speed) en parle et il y a, bien sĂ»r, la [JEP 371](https://openjdk.java.net/jeps/371) qui dĂ©crit cette Ă©volution. C’est donc une Ă©tape de plus sur la route de la suppression des classes de `sun.misc.Unsafe`. ### Sous le capot - cette version inclut la prise en charge des signatures [EdDSA](https://fr.wikipedia.org/wiki/EdDSA "Edwards‐Curve Digital Signature Algorithm") ([JEP 339](https://openjdk.java.net/jeps/339)) ; - l’API `DatagramSocket` bĂ©nĂ©ficie d’une rĂ©implĂ©mentation ([JEP 373](https://openjdk.java.net/jeps/373)). ### En vrac - nouvelles mĂ©thodes pour obtenir une valeur absolue : [JDK‐8241374](https://bugs.openjdk.java.net/browse/JDK-8241374) ; - ajout de Unicode 13 : [JDK‐8239383](https://bugs.openjdk.java.net/browse/JDK-8239383) ; - mise Ă  jour Ă  la [version 37 de la base Unicode CLDR](http://cldr.unicode.org/index/downloads/cldr-37) pour amĂ©liorer l’internationalisation de vos logiciels ; - l’AppCDS gĂšre dĂ©sormais les lambdas, ce qui permet [d’accĂ©lĂ©rer encore un peu](https://twitter.com/gunnarmorling/status/1272454820474085377) le dĂ©marrage de la JVM ; - Les Ă©numĂ©rations peuvent dĂ©sormais contenir 4 103 constantes [JDK‐8241798](https://bugs.openjdk.java.net/browse/JDK-8241798) ! ## Avant‐premiĂšres Les fonctionnalitĂ©s ci‐dessous sont considĂ©rĂ©es comme en avant‐premiĂšre (_preview_), elles sont sujettes Ă  changement d’une version Ă  l’autre. ### Filtrage par motif avec instanceof La [filtrage par motif](https://fr.wikipedia.org/wiki/Filtrage_par_motif) (_pattern matching_) sur `instanceof` ([JEP 383](https://openjdk.java.net/jeps/383)) permet de discriminer un objet selon sa classe et de rĂ©cupĂ©rer une rĂ©fĂ©rence correctement typĂ©e. Un exemple possible serait : ```java Object myVar = foo(); if (myVar instanceof String s) { System.out.println(s); } ``` Cela n’est pas encore disponible avec l’instruction `switch`. ### Sealed classes Les _sealed classes_ sont des classes dont on contrĂŽle l’hĂ©ritage. Cela permet d’avoir une connaissance Ă  la compilation de toutes les classes filles de cette derniĂšre. Le premier gain est de pouvoir s’assurer qu’on a gĂ©rĂ© tous les cas dans un `switch` qui vĂ©rifie le type par `instanceof`. C’est dĂ©crit dans la [JEP 360](https://openjdk.java.net/jeps/360). L’écriture est assez diffĂ©rente de ce que l’on trouve en Scala. Ce dernier oblige Ă  ce que toutes les classes filles soient dĂ©crites dans le mĂȘme fichier. Java garde la volontĂ© d’avoir (en principe) une seule classe par fichier. Cela s’écrit donc ainsi : ```java package org.linuxfr; public abstract sealed class Contenu permits org.linuxfr.Depeche, org.linuxfr.Journal, org.linuxfr.Lien { // ... } ``` Il faut voir que cela remet en cause les possibilitĂ©s d’étendre le code. Ça sert quasi uniquement quand on a besoin de l’_exhaustive checking_ au sein du _pattern matching_. Pour bien dĂ©crire l’intĂ©rĂȘt, cela permet d’écrire : ```java String foo(Contenu c) { return switch(c) { case Depeche d -> "plouf"; case Journal j -> "plif"; case Lien l -> "plof"; }; } ``` Sans avoir besoin d’avoir un cas `default`. ### Records Les _records_ (apparus dans la prĂ©cĂ©dente version de Java) sont des classes immuables qui bĂ©nĂ©ficient d’une syntaxe succincte. Cette mise Ă  jour assure le bon fonctionnement avec les _sealed classes_ et sur l’usage d’annotations, mais la [JEP 384](https://openjdk.java.net/jeps/384) est trĂšs complĂšte pour dĂ©crire tout leur fonctionnement. Pour ce qui est du code un `Point` en deux dimensions se dĂ©clarera comme ça : ```java record Point(int x, int y) {} ``` Et elle s’utilise comme n’importe quelle classe. Comme pour le constructeur vide crĂ©Ă© par dĂ©faut, pour vous ici le langage dĂ©finit le `equals()`/`hashCode()`, les _getter_ (avec un style « _builder_ », dans l’exemple on a `x()` et `y()`), le constructeur avec le profil que vous avez dĂ©fini et une mĂ©thode `toString()`. Comme pour le constructeur par dĂ©faut, il est possible de surcharger les implĂ©mentations fournies. Cela devrait rĂ©duire l’intĂ©rĂȘt de [lombok](https://projectlombok.org/) ou [immutables](https://immutables.github.io/). Cette nouvelle itĂ©ration apporte diverses Ă©volutions plus ou moins discrĂšte : * il y a l’interdiction d’utiliser `this` dans le constructeur canonique, c’est la solution trouvĂ©e pour Ă©viter aux dĂ©veloppeurs peu attentionnĂ©s de faire n’importe quoi ; * une modification tardive fait que les attributs des _records_ deviennent rĂ©ellement finals et ne peuvent pas ĂȘtre modifiĂ©s par rĂ©flexion [JDK‐8247444](https://bugs.openjdk.java.net/browse/JDK-8247444) ; * la possibilitĂ© de crĂ©er des `records` locaux de la mĂȘme maniĂšre que les classes ; * les [mĂ©canismes de sĂ©rialisation et de dĂ©sĂ©rialisation](https://inside.java/2020/07/20/serializablerecords/) propre et qui, donc, diffĂšrent des classes : * la sĂ©rialisation est basĂ©e seulement sur l’état de l’objet, * la « dĂ©sĂ©rialisation » utilise uniquement le constructeur canonique. La version finale sera certainement livrĂ©e en version 16. # ÉcosystĂšme ## fast‐jar Le projet [Quarkus](https://en.wikipedia.org/wiki/Quarkus) est un cadriciel Java alternatif Ă  Spring visant l’extrĂȘme performance et Ă  ĂȘtre _developer friendly_. Sa version 1.5 propose un nouvel empaquetage pour les applications Java nommĂ© fast‐jar. Un fichier au format JAR est une archive ZIP des applications Java contenant les classes compilĂ©es ainsi que quelques fichiers de description et des fichiers de configuration de l’application. Il est possible d’y inclure les bibliothĂšques utilisĂ©es par l’application : c’est ce que l’on appelle un fat‐jar ou un uber‐jar. C’est un peu comme une compilation statique, cela permet de distribuer l’application avec un unique fichier (il faut « juste » avoir un JDK installĂ©). La simplicitĂ© de ces uber‐jar leur a fait rencontrer un vif succĂšs, mais l’arrivĂ©e de Docker a un peu changĂ© la donne. Le systĂšme de couches de Docker (une image Docker dĂ©pend d’une prĂ©cĂ©dente image dont on a modifiĂ© le contenu) pousse Ă  organiser ses images comme suit : 1. l’image de base contenant le JDK ; 2. on ajoute les dĂ©pendances de l’application dans une couche dĂ©diĂ©e ; 3. on ajoute l’application dans une autre couche ; 4. si applicable, on ajoute les fichiers de configuration dans une derniĂšre couche. L’idĂ©e sous‐jacente est de dĂ©couper les couches en fonction de la frĂ©quence de mise Ă  jour : 1. on modifie plus frĂ©quemment sa configuration que l’application ; 2. on met Ă  jour plus frĂ©quemment l’application que ses dĂ©pendances ; 3. on met Ă  jour plus frĂ©quemment les dĂ©pendances que le JDK. Cela permet de ne tĂ©lĂ©charger que les derniĂšres couches lors des mises Ă  jour. Lors de leurs tests de performance, les dĂ©veloppeurs de Quarkus se sont rendu compte que le temps de dĂ©marrage d’une application uber‐jar est bien plus court qu’avec les dĂ©pendances sĂ©parĂ©es ([voir ici](https://twitter.com/agoncal/status/1298205802709364737)). Pour pouvoir Ă  la fois avoir un empaquetage Java efficace et continuer de suivre les bonnes pratiques Docker, ils ont crĂ©Ă© fast‐jar. Il s’agit simplement d’un JAR Ă©clatĂ©, mais qui possĂšde un index dans le JAR principal qui indique oĂč trouver chaque classe. Le chargeur de classes n’a donc plus Ă  aller chercher dans chaque JAR si la classe qu’il cherche s’y trouve ou non. ## DĂ©veloppement du JDK La version 16 du JDK donnera quelques modifications importantes dans son dĂ©veloppement : - passage Ă  C++14 ([JEP 347](https://openjdk.java.net/jeps/347)) ; actuellement cantonnĂ© Ă  C++98, les nouveaux dĂ©veloppements seront effectuĂ©s avec la norme C++14, la JEP dĂ©crit ce qui est autorisĂ© ou non d’utiliser ; - [_devnewton_ en avait parlĂ© dans les liens](https://linuxfr.org/users/devnewton/liens/l-openjdk-abandonne-mercurial-pour-git) : passage de Mercurial Ă  Git ([JEP 357](https://openjdk.java.net/jeps/357)), cette dĂ©cision est motivĂ©e par la taille de l’historique, l’outillage autour de Git et les hĂ©bergements disponibles pour Git — justement, dans la foulĂ©e, il a Ă©tĂ© dĂ©cidĂ© de partir chez GitHub ([JEP 369](https://openjdk.java.net/jeps/369)) ; vous trouverez les raisons de ce changement dans la JEP associĂ©e : _[Why GitHub?](https://openjdk.java.net/jeps/369#Why-GitHub?)_ ## Java champions Les _Java Champions_ sont un groupe de promoteurs de Java indĂ©pendants d’Oracle (ou de Sun Ă  l’époque). Les membres sont Ă©lus par leurs pairs (et sont aussi proposĂ©s Ă  l’élection de cette façon). Le 5 mai dernier, Audrey Neveu Ă©tait Ă©lue _Java Champion_. Elle travaille chez [Pivotal](https://en.wikipedia.org/wiki/Pivotal_Software) comme dĂ©veloppeuse Java, Kotlinv et JS, et est surtout connue en tant que membre des _[Cast Codeurs](https://lescastcodeurs.com/)_ oĂč elle sensibilise aux enjeux sociĂ©taux que les technologies peuvent poser (les risques liĂ©s aux libertĂ©s, les problĂšmes que les GAFAM peuvent induire...). ## Vingt‐cinq ans de Java Le 25 mai dernier Java a soufflĂ© ses vingt‐cinq bougies. Ça a Ă©tĂ© l’occasion de crĂ©er diffĂ©rents Ă©vĂšnements : par exemple, Oracle a mis en ligne _[Moved by Java](https://www.oracle.com/java/moved-by-java/)_, et ParisJUG a organisĂ© une soirĂ©e rĂ©trospective avec plusieurs champions Java francophones c’est [visible sur YouTube](https://www.youtube.com/watch?v=ocQeuV8vejw). On y retrouve pĂȘle‐mĂȘle : - [Audrey Neveu](https://twitter.com/audrey_neveu), nouvelle championne ; - [Antonio Gonçalves](https://antoniogoncalves.org/), cofondateur du ParisJUG, de Devoxx France, il travaille pas mal autour de Java EE ; - [Emmanuel Bernard](https://emmanuelbernard.com/), dĂ©veloppeur Red Hat sur les projets Hibernate et maintenant Quarkus ; - [Jean‐Michel Doudoux](https://www.jmdoudoux.fr/) il a produit Ă©normĂ©ment de documentations autour de Java, entre autres sur _[Developpez.com](https://jmdoudoux.developpez.com/cours/developpons/java/)_, il en publie aussi sur son [propre site](http://www.jmdoudoux.fr/accueil_java.htm) ; - [RĂ©mi Forax](http://www-igm.univ-mlv.fr/~forax/), enseignant Ă  l’universitĂ©, il est contributeur OpenJDK depuis trĂšs longtemps. Il y a aussi un article sympa listant [25 super‐applications](https://blogs.oracle.com/javamagazine/the-top-25-greatest-java-apps-ever-written). ## AdoptOpenJDK devient Adoptium AdoptOpenJDK est une distribution de Java trĂšs populaire. Elle a rejoint en juin dernier la [fondation Eclipse](https://blog.adoptopenjdk.net/2020/06/adoptopenjdk-to-join-the-eclipse-foundation/). Il peut ĂȘtre compliquĂ© d’un point de vue lĂ©gal d’utiliser le nom « OpenJDK », il a donc Ă©tĂ© choisi de renommer le projet [Eclipse Adoptium](https://projects.eclipse.org/projects/adoptium). Cela va permettre au projet de bĂ©nĂ©ficier de toute l’infrastructure proposĂ©e par Eclipse d’un point de vue technique (hĂ©bergement par exemple) et organisationnel (la gouvernance n’est pas attachĂ©e Ă  une Ă©ventuelle entreprise).

AltStyle ă«ă‚ˆăŁăŠć€‰æ›ă•ă‚ŒăŸăƒšăƒŒă‚ž (->ă‚ȘăƒȘă‚žăƒŠăƒ«) /