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).
Sommaire
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 et l’architecture SPARC, rendus obsolètes par la dernière version, ne sont plus pris en charge (JEP 381) — cocasse quand on connaît les débuts du langage ;
- Nashorn, le moteur JavaScript inclus dans le JDK, a lui aussi été retiré (JEP 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) ;
-
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).
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. 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. 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 (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.
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.
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). 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 :
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 en parle et il y a, bien sûr, la JEP 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 (JEP 339) ;
- l’API
DatagramSocketbénéficie d’une réimplémentation (JEP 373).
En vrac
- nouvelles méthodes pour obtenir une valeur absolue : JDK‑8241374 ;
- ajout de Unicode 13 : JDK‑8239383 ;
- mise à jour à la version 37 de la base Unicode CLDR 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 le démarrage de la JVM ;
- Les énumérations peuvent désormais contenir 4 103 constantes 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 (pattern matching) sur instanceof (JEP 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 :
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.
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 :
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 :
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 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 :
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 ou immutables.
Cette nouvelle itération apporte diverses évolutions plus ou moins discrète :
- il y a l’interdiction d’utiliser
thisdans 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 ;
- la possibilité de créer des
recordslocaux de la même manière que les classes ; - les mécanismes de sérialisation et de désérialisation 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 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 :
- l’image de base contenant le JDK ;
- on ajoute les dépendances de l’application dans une couche dédiée ;
- on ajoute l’application dans une autre couche ;
- 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 :
- on modifie plus fréquemment sa configuration que l’application ;
- on met à jour plus fréquemment l’application que ses dépendances ;
- 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). 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) ; 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 : passage de Mercurial à Git (JEP 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) ; vous trouverez les raisons de ce changement dans la JEP associée : 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 comme développeuse Java, Kotlinv et JS, et est surtout connue en tant que membre des Cast Codeurs 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, et ParisJUG a organisé une soirée rétrospective avec plusieurs champions Java francophones c’est visible sur YouTube. On y retrouve pêle‑mêle :
- Audrey Neveu, nouvelle championne ;
- Antonio Gonçalves, cofondateur du ParisJUG, de Devoxx France, il travaille pas mal autour de Java EE ;
- Emmanuel Bernard, développeur Red Hat sur les projets Hibernate et maintenant Quarkus ;
- Jean‑Michel Doudoux il a produit énormément de documentations autour de Java, entre autres sur Developpez.com, il en publie aussi sur son propre site ;
- Rémi Forax, enseignant à l’université, il est contributeur OpenJDK depuis très longtemps.
Il y a aussi un article sympa listant 25 super‑applications.
AdoptOpenJDK devient Adoptium
AdoptOpenJDK est une distribution de Java très populaire. Elle a rejoint en juin dernier la fondation Eclipse. 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. 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).
Aller plus loin
- OpenJDK 15 (98 clics)
- Quarkus 1.5 (75 clics)
# Immutables
Posté par ckyl . Évalué à 5. Dernière modification le 15 septembre 2020 à 17:22.
Oui est non. Non pour la partie construction d'objets immutables complexes. Dès que tu sors des cas d'exemple à 4 attributs, en l'absence de paramètres nommés, on n'a toujours pas d'autre solution que le builder pattern pour avoir quelque chose de vaguement lisible et maintenable. Cette partie a été délibérément mise hors périmètre des records, donc leur principal intérêt c'est côté mémoire & perf et boilerplate.
[^] # Re: Immutables
Posté par barmic 🦦 . Évalué à 3.
C'est pour ça que je parlais de réduire.
C'est pas ce qu'ils indiquent pour la mémoire et la perf :
Je ne vois rien qui parle de performance ou de mémoire, par contre je trouve drôle qu'ils cherchent à simplifier la création de structures simples sans faire la guerre au boilerplate. Je comprends plus ou moins l'idée, mais la façon dont c'est présenté dans la JEP me semble surtout chercher à montrer qu'ils ne veulent pas intégrer cette syntaxe dans les objets classiques.
De mon humble avis l'un des gros objectif finaux des records même si ce n'est pas encore implémenté c'est de pouvoir les déconstruires.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Immutables
Posté par Nonolapéro . Évalué à 4.
C’est un des projets en cours. Brian Goetz a écrit deux articles à ce sujet.
Les plus curieux pourront aussi lire les documents présent ici pour se faire une idée d’où vient et vers où va Java du côté du projet Amber. Pour rappel, Amber a pour but de rendre le Java plus agréable à écrire en le rendant plus expressif et plus concis.
[^] # Re: Immutables
Posté par barmic 🦦 . Évalué à 3.
J'ai l'impression que c'est le projet qui fait le plus parler de lui. Ça me donne l'impression que le projet Coin a montré que c'est cool de faire évoluer le langage :)
Merci pour les liens
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Immutables
Posté par Nonolapéro . Évalué à 3.
Il fait parler de lui car il touche beaucoup de monde et avance de manière assez visible mais globalement ça ne touche pas vraiment au cœur du langage. Le projet Loom est également très attendu et ne devrait plus trop tarder (au pif, moins de deux ans). Il apportera les thread légers manipulables par million en ne changeant que quelques petits trucs.
Dans ce code il suffit de mettre Ă jour la boucle avec
[^] # Re: Immutables
Posté par ckyl . Évalué à 3.
J'avais Valhalla en tête qui n'est clairement pas dans le périmètre des record et des JEP actuelles mais qui introduit pour contrainte:
Après avoir relu le state of Valhalla, la dépendance record / inline est faible, techniquement inexistante, mais "tire dans la bonne direction".
Tu as parfaitement raison sur la déconstruction.
[^] # Re: Immutables
Posté par barmic 🦦 . Évalué à 3.
J'avais adoré la présentation de Rémi Forax là dessus à devoxx France, il pensait qu'on aurait les inline pour java 10 (j'adore son optimisme
^^).https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Immutables
Posté par Benoît Sibaud (site web personnel) . Évalué à 9.
Forcément c'est compliqué après Java :).
« True is the new false » comme ne disait pas D. Trump.
# Java 15, le nouveau Kotlin ? (mais un peu en retard quand mĂŞme)
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
Ça fait plaisir de voir que Java tente de rattraper son retard sur Kotlin. Dans l’ordre de la dépêche :
Évidemment les améliorations de la JVM devraient profiter à tous les langages qui l’utilisent, dont Kotlin-sur-JVM (même si le langage a l’air surtout utilisé sur Android).
Littératures de l’imaginaire, libres, pour tout le monde : https://renardspatial.com/ | La connaissance libre : https://zestedesavoir.com
[^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand mĂŞme)
Posté par Nonolapéro . Évalué à 4. Dernière modification le 16 septembre 2020 à 10:32.
En gros Java à trois ans de retard sur Kotlin mais quand il fait les choses il le fait mieux. Ce message est tiré de cette vidéo : https://www.youtube.com/watch?v=te3OU9fxC8U
[^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand mĂŞme)
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
J’aurais pas dit « mieux » d’après la vidéo. Le message que j’en retiens, c’est plutôt que Java a la possibilité de modifier directement la JVM pour mieux coller à ses évolutions, et donc que les implémentations Java des fonctionnalités peuvent être plus efficaces (le temps que Kotlin tire partie des évolutions de la JVM à son tour).
Littératures de l’imaginaire, libres, pour tout le monde : https://renardspatial.com/ | La connaissance libre : https://zestedesavoir.com
[^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand mĂŞme)
Posté par barmic 🦦 . Évalué à 3. Dernière modification le 16 septembre 2020 à 14:18.
Pourquoi kotlin plutôt que groovy, scala ou ceylon par exemple ? Clairement aucun de ses concepts n'ont était inventé par kotlin, ils ont même déjà d'autres implémentation sur la jvm. Et java a choisi des implémentations qui sont clairement distinct (sauf pour les blocs de textes, mais ça n'a pas toujours était le cas ça montre que ce n'est pas ce qui le conduit).
Avec l'organisation actuelle de l'écosystème, il me paraît normal de voir des langages arriver et faire des choses cool et d'avoir un java qui prends son temps et qui par contre a un développement couplé avec celui de la jvm, du jdk et des gc.
Quand JetBrain prends une décision et quand Amber prends une décision, ça ne prends pas le même temps et ça n'a pas le même impact.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand mĂŞme)
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 4.
Pour plusieurs raisons :
Et ça n’est pas une question d’implémentation mais clairement de fonctionnalités : en terme de fonctionnalités, Java rattrape Kotlin. Tout mon propos est là : en tant que développeur et d’utilisateur au quotidien du langage, ça fait plaisir de voir que Java ne stagne plus comme il a pu le faire à plusieurs époques, et se décide à intégrer les bonnes idées qui viennent d’ailleurs dans la « communauté ».
Littératures de l’imaginaire, libres, pour tout le monde : https://renardspatial.com/ | La connaissance libre : https://zestedesavoir.com
[^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand mĂŞme)
Posté par barmic 🦦 . Évalué à 5.
Alors oui, mais j'ai pas l'impression que ça se maintienne tant que ça. Android c'est très particulier, puisque ça n'est pas OpenJDK et je crois que ART ne cherche même plus à coller avec les nouveautés de Java (l'usage des "nouveautés" de java8 semble se faire par des extensions). Sur le JDK kotlin avait marqué par gradle qui propose maintenant kotlin comme DSL (mais gradle est écris en java) et par spring qui le supporte (on parle ici d'avoir des apis pensaient pour un usage idiomatique de spring avec kotlin), mais en soit je ne le vois pas tant décoller que ça hors Android. Je peux tout à fait me tromper, hein ? Et j'apprécie kotlin, mais je ne le vois pas arriver. Je viens de regarder, évidement ça vaut ce que ça vaut, mais dans le dernier classement tiobe groovy est 17ème, scala 31ème et kotlin 34ème. Pour te donner une idée rust est 18ème et swift est 12ème pour d'autres langages récents.
C'est aussi un peu comme ça qu'a était pense groovy avec beaucoup plus d'ambition en terme de nouveauté et un énorme intérêt pour être vraiment interfaçable avec java (contrairement à scala, tu peux utiliser une bibliothèque groovy sans te rendre compte que ce n'est pas du java - à cause de collections qui n'existe pas dans java collection, de l'utilisation d'idiomes qui n'existent pas en java et qui font bizarre à l'usage, etc).
Tu vois ça à partir de quoi ?
Ça a était "fréquent" (gradle, android et spring), mais hors de ces 3 exemples qui commencent à dater un peu je n'ai pas vu d'autres annonces de ce type passer (mais je suis intéressé si tu as des exemples).
Ça a des implications. Les sealed classes sont écrites dans différents fichiers. Si tes classes sont grosses, tu peux trouver ça intéressant. La contrepartie, c'est que ta classe doit aussi être déclarée dans la classe mère ce qui est un peu plus moche (c'est moins DRY). Le pettern matching de java oblige à créer de nouvelles références tu ne pourra jamais écrire :
Ces choix ne sont pas vraiment anodins.
Tout à fait d'accord. Je pense qu'à terme ça aurait posé de graves souci à Java. Comme C++, ils se sont donné un rythme et ça accélère les évolutions et c'est vraiment bien.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand mĂŞme)
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
Pour l’utilisation de Kotlin, je me base plus sur mon expérience et surtout ce que je vois de son support un peu partout, que sur des index aussi bancals de TIOBE (dont la courbe contient des sautes impressionnantes et inexpliquées). Or Kotlin est de plus en plus supporté, depuis les gros et anciens frameworks à la mode comme Spring aux nouveaux frameworks à la mode comme Quarkus.
C’est tout l’intérêt de Kotlin : son principe de base, c’est d’abord et avant tout d’être pratique et agréable à utiliser en leur permettant de se concentrer sur ce qui est important dans le code, pas sur des détails type boilerplate (« A modern programming language that makes developers happier. » d’après eux). Ça fait hurler les puristes des langages et les chercheurs, mais à l’usage dans l’industrie c’est infiniment plus agréable à utiliser que, par exemple, Scala qui lui a une conception orientée par la théorie.
La popularité de Groovy par rapport à Kotlin, je la vois à la fois par rapport à mon expérience personnelle et par rapport aux tendances de recherche sur Google.
Littératures de l’imaginaire, libres, pour tout le monde : https://renardspatial.com/ | La connaissance libre : https://zestedesavoir.com
[^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand mĂŞme)
Posté par ckyl . Évalué à 8.
Si tu as un peu de bouteille dans l'industrie et que tu n'écris pas des applications jetables à court terme, la stratégie payante c'est:
C'est long, trèès long mais moins que d'avoir du réécrire sa base de code en 5 langages en 15 ans ou de se retrouver avec un mélange de 3 ou 4 :)
Kotlin ne sera pas différent, dans 2..5 ans il n'aura plus d'avantage très significatif et tu te retrouveras avec une base de code dont tu ne sauras pas quoi faire par ce qu'autant l'interop Java <-> autre c'est pas toujours fou mais l'interop autre1 <-> autre2 c'est la déprime totale.
Bref plus tu fais du back / infra plus le ROI est discutable. Après ça ne semble pas poser de problème fondamental à l'écosystème JS de réécrire 100 fois même chose…
Si tu perds patience, autant partir de la JVM. Android c'est différent, il n'y a pas de choix.
[^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand mĂŞme)
Posté par YBoy360 (site web personnel) . Évalué à 2.
Même si j'utilise et adore Kotlin (hors d'Android), Groovy a largement plus de légitimité pour avoir la primeur sur ces fonctionnalités.
Gradle est un très mauvais exemple de comment faire du Groovy, je pense que ça le dessert plus qu'autre chose. Mais bon, ça lui permet d'avoir une certaine présence.
# C'est pas pour casser l'ambiance
Posté par Maxzor . Évalué à -10.
mais qu'est ce que ce détritut de langage/écosystème a à faire avec une revue libriste?
[^] # Re: C'est pas pour casser l'ambiance
Posté par raphj (site web personnel) . Évalué à 10.
Parce que c'est un langage populaire avec une ou plusieurs implémentations libres, utilisé par beaucoup de logiciels libres ?
En tout cas 28 points pour la dépêche suffit à montrer qu'il y a de l'intérêt ici :-)
[^] # Re: C'est pas pour casser l'ambiance
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10.
Si tu as des vrais arguments contre Java (des qui existent encore en 2020, pas des qui datent de Java 1.4 et de plus de 20 ans) et pas des insultes, je serais curieux de les lire.
Idem pour toute personne qui plusseoierait le message de Maxzor.
Littératures de l’imaginaire, libres, pour tout le monde : https://renardspatial.com/ | La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est pas pour casser l'ambiance
Posté par devnewton 🍺 (site web personnel) . Évalué à 3.
Le seul problème de Java, c'est qu'il est grassouillet. Espérons qu'il se mette au régime un jour.
Ce post est offensant ? Prévenez moi sur https://linuxfr.org/board
[^] # Re: C'est pas pour casser l'ambiance
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
Y’a eu pas mal d’efforts en ce sens, mais la pratique habituelle ça reste quand même d’avoir une JVM avec toutes ses API, ce qui est effectivement souvent lourd pour pas grand-chose.
Littératures de l’imaginaire, libres, pour tout le monde : https://renardspatial.com/ | La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est pas pour casser l'ambiance
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Java est très verbeux, donc plus difficile à lire. Il n'est pas assez paramétrique ce qui oblige à jouer avec des @…, voir des bouts de définition en XML à coté du code, ce qui implique lourdeur, et lenteur. Une appli web qui ne fait pas grand chose : 500Mo d'artefact de gitlab…
Le type 'null' est toujours là . Les types de base ne sont pas des objets. Il n'y a pas de notion de layout mémoire, tout objet est "boxé" ce qui implique une grosse quantité de pointeur de partout. Le modèle "multi-thread" est pas top, ce n'est ni Go, ni Rust.
Les licences entre openjdk et jdk d'Oracle, ne sont pas claire. Et retrouver aujourd'hui, une jvm 8 est compliqué.
…
"La première sécurité est la liberté"
[^] # Re: C'est pas pour casser l'ambiance
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 5.
Je vois du vrai et de l’obsolète dans ce que tu écris :
Plutôt faux depuis Java 8. On est très loin de la verbosité de Java jusqu’à 1.4 inclus.
Sur un projet moderne, ça fait des années que je n’ai plus eu à configurer quoi que ce soit en XML à côté du code en Java. Quant à la lourdeur et la lenteur incluses parce que « pas assez paramétrique », je suis réellement curieux d’avoir un exemple de ce que tu entends par là (c’est une vraie question, pas un troll).
Ha ? Tu utilises quoi comme framework ? J’ai un projet perso avec Spring Boot + Kotlin + connexion à la BDD + génération de pages en HTML avec Thymeleaf, je râlais parce que le JAR exécutable (et unique fichier produit) était passé de 49 à 65 Mo en passant à la dernière version de Spring Boot. C’est objectivement gros, surtout quand Quarkus peut produire des binaires natifs beaucoup plus petits (mais sur des piles moins grosses), mais un ordre de grandeur sous ce que tu donnes.
Tout ça, OK (et à mon sens le
nullest peut-être le plus gros problème de Java). Il y avait un projet pour se débarasser des types de base, mais ça fait longtemps que je n’en ai plus entendu parler.Et du coup ça implique quoi comme problème, vu que tu ne manipules jamais de pointeur en Java ?
C’est assez vrai, mais Java date de 1996, Go de 2009, Rust de 2010. Les API récentes ont aussi beaucoup amélioré l’utilisation des threads, et on trouve des API réactives tout à fait convaincantes et performantes depuis peu.
C’est en effet un problème, de même que les incompatiblités entre les différents fournisseurs de JVM/JDK (on les rencontre surtout pour les modes graphiques).
10 secondes chrono si tu connais le nom de AdoptOpenJDK (qui est Ă connaitre si tu travailles avec Java).
Littératures de l’imaginaire, libres, pour tout le monde : https://renardspatial.com/ | La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est pas pour casser l'ambiance
Posté par barmic 🦦 . Évalué à 4.
Attendons que ces langages aient 10 ans, pour voir apparaître ce genre de choses (à mon avis go y passera et rust non grâce aux macro). Grosso modo soit tu prévois de la métaprogrammation dans ton langage de base soit tu prévois un métalangage ou un outillage autour (comme python, C, C++, C#,…).
Les records sont entre autre là pour ça.
openjdk c'est du gplv2 je vois pas la complexité. Je vois pas en quoi la notion de distribution est compliquée pour des gens habitués à leurs distributions linux.
Je vois pas la difficulté.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est pas pour casser l'ambiance
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Ou est le jdk 8 dans la page OpenJDK ?
"La première sécurité est la liberté"
[^] # Re: C'est pas pour casser l'ambiance
Posté par barmic 🦦 . Évalué à 2.
OpenJDK ne fais pas de distribution. C'est comme aller sur la lkml pour télécharger linux. Tu peux mais du coup il faut comprendre que tu récupère une archive d'un dépôt. Donc pour openjdk, tu clique sur mercurial puis sur jdk8 et tu va pouvoir récupérer le jdk8 en bz2, zip ou gz. Ce n'est pas facile, mais dis-toi que tu va même devoir le compiler ton JDK. Encore une fois c'est comme d'aller chercher ton noyau sur lkml.org
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est pas pour casser l'ambiance
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
On est bien d'accord, il n'y a pas de package de jdk sur openjdk. Donc, pourquoi en parler ?
"La première sécurité est la liberté"
[^] # Re: C'est pas pour casser l'ambiance
Posté par barmic 🦦 . Évalué à 4.
Parce que je ne vois pas ce que tu entend par "on trouve plus le jdk8" tous les endroits où on peut logiquement chercher en parlent dès leur page d'accueil. Même les moteurs de recherche ont des résultats pertinents dans les premiers liens.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est pas pour casser l'ambiance
Posté par Nicolas Boulay (site web personnel) . Évalué à 0.
Ce qui est faux. openjdk ne le propose pas. Le lien oracle propose le jdk oracle.
Il reste l'autre lien qui n'apparaissait pas quand j'avais fait la recherche.
Dire que trouver un openjdk 8 est simple est faux. Il n'est disponible que dans les vieilles distro ou sur https://adoptopenjdk.net/
"La première sécurité est la liberté"
[^] # Re: C'est pas pour casser l'ambiance
Posté par claudex . Évalué à 5.
Il y a deux clics à faire sur adoptopenjdk, je ne vois pas comment tu peux trouver ça compliquer (et c'est le 4e site chez Google chez moi si je tappe "download openjdk 8").
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est pas pour casser l'ambiance
Posté par barmic 🦦 . Évalué à 3.
Si t'es pas satisfait de ta distro, ce n'est probablement pas la faute du projet upstream1. RHEL possède toujours la version 8 du JDK par exemple. Après ta distribution a peut être des arguments comme « on ne supporte que la dernière version LTS » ce qui a du sens (tous les projets ne maintiennent pas plusieurs versions LTS en parallèle).
les sources sont toujours disponibles, le dernier commit sur le dépôt a 6 jours donc je présume que ta distribution a accès au code à jour du JDK ↩
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est pas pour casser l'ambiance
Posté par ckyl . Évalué à 6. Dernière modification le 24 septembre 2020 à 19:12.
Petit résumé de comment fonctionne l'écosystème Java:
Oracle JDK correspond Ă ce dernier cas. Pour Java 8 ils ont arrĂŞtez de filer gratuitement un JDK 8 et n'en fournissent plus qu'Ă leur client.
Si tu veux un JDK 8 open source gratuit, il suffit de choisir ton fournisseur:
Je crois que tu n'as juste pas compris comment ça fonctionne et que tu fais beaucoup de vagues pour un petit changement de stratégie de la part d'Oracle JDK.
Pour plus de détails: https://docs.google.com/document/d/1nFGazvrCvHMZJgFstlbzoHjpAVwv5DEdnaBr_5pKuHo/edit
Si tu veux essayez différent JDK il existe l'excellent SDKMAN, https://sdkman.io/jdks
[^] # Re: C'est pas pour casser l'ambiance
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
J’ajoute qu’en plus de l’OpenJDK, il y a d’autres JDK alternatifs. Le plus utilisé (et qui reste vraiment un JDK, pas un machin étrange comme GraalVM) est sans doute J9, le JDK d’IBM, qui est récemment passé chez la fondation Eclipse.
Jusqu’à Java 6, il était sensiblement plus performant que le JDK d’Oracle, mais ça n’est plus le cas. Il est obligatoire pour certains produits IBM, et son implémentation est complètement différente, y compris les classes de l’API.
Littératures de l’imaginaire, libres, pour tout le monde : https://renardspatial.com/ | La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est pas pour casser l'ambiance
Posté par claudex . Évalué à 3.
Moi qui ne suit pas dans l'ecosystème Java, je ne vois pas trop l'intérêt de J9. Quelqu'un a des arguments pour/contre ?
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est pas pour casser l'ambiance
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
L’argument « pour » était tout simplement que pendant longtemps, les produits IBM refusaient de se lancer (ou se comportaient n’importe comment) s’ils n’utilisaient pas J9…
Si tu étais riche (parce que la licence n’était pas donnée si tu voulais utiliser J9 autrement que pré-packagé avec un produit IBM) et que tu avais besoin d’un peu plus de performances, jusqu’à Java 1.5 inclus, ça pouvait être aussi une solution à étudier.
Littératures de l’imaginaire, libres, pour tout le monde : https://renardspatial.com/ | La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est pas pour casser l'ambiance
Posté par barmic 🦦 . Évalué à 2.
Ça me fait penser à jrokit (qui fut la première à faire de déchargement de classe il me semble) et l'époque de bea puis d'oracle.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est pas pour casser l'ambiance
Posté par claudex . Évalué à 3.
Mais du coup, il n'y a plus d'arguments actuellement ? (Sans doute pour ça qu'IBM l'a abandonné)
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: C'est pas pour casser l'ambiance
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
Aujourd’hui, si tu n’as pas de raison extérieure impérative d’utiliser J9, la seule raison que je vois c’est pour le plaisir d’utiliser une alternative. Il y a peut-être des cas spécifiques particuliers où elle est intéressante, mais de but en blanc je n’en connais pas.
Littératures de l’imaginaire, libres, pour tout le monde : https://renardspatial.com/ | La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est pas pour casser l'ambiance
Posté par ckyl . Évalué à 4.
La plaquette commerciale: https://www.eclipse.org/openj9/performance/
En gros ils se positionnent sur une VM un poil plus adaptée aux microservice (footprint un poil plus bas cas et démarrage plus rapide au détriment d'un poil moins de perf en régime de croisière). On reste sur des écarts de quelques pourcents. J'ai pas testé sur des charges réelles.
[^] # Re: C'est pas pour casser l'ambiance
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
C'est encore horrible par rapport Ă d'autre langage (cf le nouveau record).
Tout ce qui concerne spring boot, la gestion d'erreur complexe à comprendre, le fait que cela ne soit plus programmatique. Si on rajoute des générateurs de code à un langage, c'est que les fonctions paramétrique sont trop pauvres.
Je sais, j'étais le premier surpris, c'était un serveur d'API avec connection Kafka (dépendance incluse).
Cela implique beaucoup de lenteurs (les cpu n'aiment pas les indirections mémoires) et beaucoup de consommation mémoire par rapport à une structure identique en C++, par exemple.
Tu penses Ă quoi ?
J'en étais resté que JavaFX n'était plus géré. Tu penses à autres choses ?
Cela aurait pu me servir il y a quelques temsp :)
"La première sécurité est la liberté"
[^] # Re: C'est pas pour casser l'ambiance
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 3.
Heu… tu est sérieux là  ? Le seul truc de « verbeux » dans un
record, c’est les accolades à la fin dont on se demande un peu ce qu’elles font là  :On ne peut pas vraiment dire que ça rends le truc illisible…
La gestion d’erreurs (en particulier les checked exceptions) est connu comme l’une des erreurs de conception du langage, entre autres par certains concepteurs du langage. Je ne comprends pas ce que tu veux dire par « Tout ce qui concerne spring boot, » et « le fait que cela ne soit plus programmatique. ».
La consommation mémoire, pourquoi pas (et encore, le gros de la consommation mémoire en Java, c’est surtout des gens qui ne savent pas s’en servir et qui font des fuites mémoires partout, et qui laissent les paramètres à des valeurs démesurément hautes). Les performances… Java peut monter franchement haut en performances, notamment pour un langage non compilé en natif.
Concernant les threads, il y a eu le framework Executor et ses évolutions futures, et il me semble que ça a encore été amélioré depuis.
Pour les frameworks recatifs, je pense Ă des choses comme RxJava ou Spring Reactor.
Concernant les différences entre JVM/JDK, quelques exemples ici.
Littératures de l’imaginaire, libres, pour tout le monde : https://renardspatial.com/ | La connaissance libre : https://zestedesavoir.com
[^] # Re: C'est pas pour casser l'ambiance
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Je voulais dire que record essaye justement de palier le problème. Mais ce n'est qu'un paquet de donné.
Si tu code à coup de @…, tu ne codes plus vraiment. C'est de la déclaration statique au milieu d'un truc qui est dynamique, et parfois cela marche mal. Et typiquement, comprendre une erreur provenant de là n'est pas simple.
Oui, et une des grosses différences avec C++ est justement cette fragmentation et ces sauts mémoires.
"La première sécurité est la liberté"
[^] # Re: C'est pas pour casser l'ambiance
Posté par barmic 🦦 . Évalué à 6.
Tu as déjà vu une appli qui était grosse donc java fais de grosses appli ?
En contrepartie tu évite la fragmentation de la mémoire et le CPU n'aime pas non plus la fragmentation mémoire.
Ce n'est plus dans le JDK, c'est loin d'ĂŞtre mort https://openjfx.io/
Oui quand on suit de loin un écosystème ça peut paraître difficile à suivre ou comprendre. Mais je ne trouve pas surprenant qu'il faille un peu s'intéresser à un sujet pour le comprendre…
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est pas pour casser l'ambiance
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Java a cette réputation, qu'un exemple confirme. Mais je serais le seul à le penser…
Qu'est-ce que tu veux dire par là ? La fragmentation mémoire est dû à l'allocation de petit bout de mémoire à la place de gros. Vu que chaque objet est alloué indépendamment dans Java, et qu'une grosse structure de structure est impossible, la mémoire sous Java est bien plus fragmenté et une structure de structure est sous forme de structure de pointeur.
Peut être que tu veux parler de la compaction faite par le GC, mais ce n'est fait que part le code "stop the world" qui est évité à tout prix.
"La première sécurité est la liberté"
[^] # Re: C'est pas pour casser l'ambiance
Posté par barmic 🦦 . Évalué à 4.
Non la fragmentation est due à la non réutilisation de l'espace libéré. Allouer un grand espace est une technique pour limiter la fragmentation.
Lire la dépêche que l'on commente peut être une bonne idée ;)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: C'est pas pour casser l'ambiance
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
En bref ça :
ne veut rien dire. Gaspiller de la mémoire ne coute rien en temps cpu.
"La première sécurité est la liberté"
[^] # Re: C'est pas pour casser l'ambiance
Posté par kantien . Évalué à 1.
C'est étrange comme projet, j'aurais plutôt eu l'idée contraire : virer les objets et n'avoir que des types comme ceux de base. :-)
Un type c'est un concept et l'interface d'une classe la définition d'un concept (celui mal fait d'algèbre sur un concept). Celui qui définit ses concepts comme des classes s'y prend aussi mal que ce qui est reproché dans le texte ci-dessus. Si au lieu de ce théorème, on prend le fait qu'un cercle a une circonférence dont la valeur est le diamètre multiplié par une constante (Pi) et que l'on met cela dans une méthode d'une classe, alors on définit le cercle comme une quiche sur patte. ;-)
Le problème étant que, si l'on a que des classes, ce défaut qui touche à la forme des définitions, au lieu d'être rare, se retrouve être permanent.
Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.
[^] # Re: C'est pas pour casser l'ambiance
Posté par collinm (site web personnel) . Évalué à 3.
plutôt faux, peut-être verbeux mais tellement + simple à lire surtout plusieurs mois après avoir écrit le code…. comparativement à du ruby ou du c, c++ où tu peux arriver à du code concis…. mais tellement difficile à lire…. d'ailleurs pas toujours évident avec les lambdas
www.solutions-norenda.com
# juste une coquille Ă corriger
Posté par srb (site web personnel) . Évalué à 1.
swicth->switch[^] # Re: juste une coquille Ă corriger
Posté par Benoît Sibaud (site web personnel) . Évalué à 3.
Corrigé, merci.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.