Java 15 est sorti

Posté par barmic 🦦 le 15 septembre 2020 à 14:47. Édité par bobble bubble, Nonolapéro, Yves Bourguignon, Benoît Sibaud, Lawless, BAud, Davy Defaud, theojouedubanjo et Ysabeau 🧶. Modéré par Ysabeau 🧶. Licence CC By‑SA.

Étiquettes :

sept.

2020

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 DatagramSocket bé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 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 ;
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 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 (94 clics)
Quarkus 1.5 (72 clics)

# Immutables

Posté par ckyl le 15 septembre 2020 à 17:17. Évalué à 5. Dernière modification le 15 septembre 2020 à 17:22.

Records […] Cela devrait réduire l’intérêt de lombok ou immutables.

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 🦦 le 15 septembre 2020 à 17:58. Évalué à 3.
  C'est pour ça que je parlais de réduire.
  
  donc leur principal intérêt c'est côté mémoire & perf et boilerplate.
  
  C'est pas ce qu'ils indiquent pour la mémoire et la perf :
  Goals
  - Devise an object-oriented construct that expresses a simple aggregation of values.
  - Help programmers to focus on modeling immutable data rather than extensible behavior.
  - Automatically implement data-driven methods such as equals and accessors.
  - Preserve long-standing Java principles such as nominal typing and migration compatibility.
  Non-Goals
  - It is not a goal to declare a "war on boilerplate". In particular, it is not a goal to address the problems of mutable classes which use the JavaBeans naming conventions.
  - It is not a goal to add features such as properties or annotation-driven code generation, which are often proposed to streamline the declaration of classes for "Plain Old Java Objects".
  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 le 15 septembre 2020 à 20:03. Évalué à 4.
    
    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.
    
    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 🦦 le 15 septembre 2020 à 22:58. Évalué à 3.
      
      Pour rappel, Amber a pour but de rendre le Java plus agréable à écrire en le rendant plus expressif et plus concis.
      
      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 le 16 septembre 2020 à 00:37. É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.
        
        public class Main { public static void main(String[] args) { var c = new AtomicLong(); // Attention même pas certain que ça aille au bout for (var i = 0; i < 1_000_000; i++) { new Thread(() -> { c.incrementAndGet(); }).start(); } System.out.println(c.get()); } }
        
        Dans ce code il suffit de mettre à jour la boucle avec
        
        for (var i = 0; i < 1_000_000; i++) { Thread.startVirtualThread(() -> { c.incrementAndGet(); }); }
  - [^] # Re: Immutables
    
    Posté par ckyl le 15 septembre 2020 à 20:59. É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:
    
    Inline classes are heterogeneous aggregates that explicitly disavow object identity. As a result, they must be immutable, and cannot be layout-polymorphic;
    
    Après avoir relu le state of Valhalla, la dépendance record / inline est faible, techniquement inexistante, mais "tire dans la bonne direction".
    - https://cr.openjdk.java.net/~briangoetz/valhalla/sov/01-background.html
    - https://cr.openjdk.java.net/~briangoetz/valhalla/sov/02-object-model.html
    Tu as parfaitement raison sur la déconstruction.
    - [^] # Re: Immutables
      
      Posté par barmic 🦦 le 16 septembre 2020 à 12:43. É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) le 15 septembre 2020 à 18:28. Évalué à 9.
  
  Oui est non.
  
  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) le 16 septembre 2020 à 10:16. Évalué à 4.
Ça fait plaisir de voir que Java tente de rattraper son retard sur Kotlin. Dans l’ordre de la dépêche :
- Les blocs de texte
- Le filtrage par motif (et ça aussi)
- Les sealed classes
- Les data classes qui ressemblent beaucoup aux records proposés
É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).

La connaissance libre : https://zestedesavoir.com
- [^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand même)
  
  Posté par Nonolapéro le 16 septembre 2020 à 10:31. É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) le 16 septembre 2020 à 11:16. É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).
    
    La connaissance libre : https://zestedesavoir.com
- [^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand même)
  
  Posté par barmic 🦦 le 16 septembre 2020 à 14:15. É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) le 16 septembre 2020 à 15:23. Évalué à 4.
    Pour plusieurs raisons :
    - Kotlin est le langage qui monte le plus dans les langages alternatifs qui tournent sur la JVM. Le fait qu’il soit poussé comme langage principal sur Android aide beaucoup.
    - C’est aussi celui qui ressemble le plus à Java (il a été pensé en gros comme « Java en mieux, avec des idées tirées de Scala, mais en plus pragmatique et plus efficace »).
    - Groovy s’est rapidement fait dépasser en popularité par Kotlin (même si Gradle l’utilise (même si on peut scipter Gradle avec Kotlin))
    - Scala, c’est plus difficile à savoir : j’ai l’impression qu’il est très utilisé dans certains milieux, mais a du mal à en sortir. Je n’ai jamais vu de vague de « OK maintenant on va utiliser Scala au lieu de Java », alors que c’est assez fréquent avec Kotlin, notamment parce que Scala est plus difficile à prendre en main (et a longtemps été lentissime à compiler).
    - Ceylon n’a jamais percé.
    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é ».
    
    La connaissance libre : https://zestedesavoir.com
    - [^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand même)
      
      Posté par barmic 🦦 le 16 septembre 2020 à 16:00. Évalué à 5.
      Kotlin est le langage qui monte le plus dans les langages alternatifs qui tournent sur la JVM. Le fait qu’il soit poussé comme langage principal sur Android aide beaucoup.
      
      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 celui qui ressemble le plus à Java (il a été pensé en gros comme « Java en mieux, avec des idées tirées de Scala, mais en plus pragmatique et plus efficace »).
      
      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).
      
      Groovy s’est rapidement fait dépasser en popularité par Kotlin (même si Gradle l’utilise (même si on peut scipter Gradle avec Kotlin))
      
      Tu vois ça à partir de quoi ?
      
      alors que c’est assez fréquent avec Kotlin, notamment parce que Scala est plus difficile à prendre en main (et a longtemps été lentissime à compiler).
      
      Ç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).
      
      Et ça n’est pas une question d’implémentation mais clairement de fonctionnalités : en terme de fonctionnalités, Java rattrape Kotlin.
      
      Ç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 :
      
      var a = foo(); if (a instanceof Integer) b+=a;
      
      Ces choix ne sont pas vraiment anodins.
      
      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é ».
      
      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) le 16 septembre 2020 à 17:19. É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 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
        
        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.
        
        La connaissance libre : https://zestedesavoir.com
        
        [^] # Re: Java 15, le nouveau Kotlin ? (mais un peu en retard quand même)
        
        Posté par ckyl le 16 septembre 2020 à 17:35. Évalué à 8.
        
        Ç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.
        
        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:
        
        tu regardes passer les langages alternatifs de la JVM
        
        tu joues avec par interet et pour les trucs mineurs
        
        tu attends qu'une partie des trucs intéressant atterrissent Java pour les choses sérieuses.
        
        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) le 19 septembre 2020 à 07:55. É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 le 16 septembre 2020 à 14:23. É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) le 16 septembre 2020 à 14:36. É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) le 16 septembre 2020 à 15:35. É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.
  
  La connaissance libre : https://zestedesavoir.com
  - [^] # Re: C'est pas pour casser l'ambiance
    
    Posté par devnewton 🍺 (site web personnel) le 17 septembre 2020 à 15:50. É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) le 17 septembre 2020 à 16:22. É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.
      
      La connaissance libre : https://zestedesavoir.com
  - [^] # Re: C'est pas pour casser l'ambiance
    
    Posté par Nicolas Boulay (site web personnel) le 22 septembre 2020 à 13:58. É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) le 22 septembre 2020 à 14:28. Évalué à 5.
      
      Je vois du vrai et de l’obsolète dans ce que tu écris :
      
      Java est très verbeux, donc plus difficile à lire.
      
      Plutôt faux depuis Java 8. On est très loin de la verbosité de Java jusqu’à 1.4 inclus.
      
      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.
      
      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).
      
      Une appli web qui ne fait pas grand chose : 500Mo d'artefact de gitlab…
      
      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.
      
      Le type 'null' est toujours là. Les types de base ne sont pas des objets.
      
      Tout ça, OK (et à mon sens le null est 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.
      
      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.
      
      Et du coup ça implique quoi comme problème, vu que tu ne manipules jamais de pointeur en Java ?
      
      Le modèle "multi-thread" est pas top, ce n'est ni Go, ni Rust.
      
      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.
      
      Les licences entre openjdk et jdk d'Oracle, ne sont pas claire.
      
      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).
      
      Et retrouver aujourd'hui, une jvm 8 est compliqué.
      
      10 secondes chrono si tu connais le nom de AdoptOpenJDK (qui est à connaitre si tu travailles avec Java).
      
      La connaissance libre : https://zestedesavoir.com
      - [^] # Re: C'est pas pour casser l'ambiance
        
        Posté par barmic 🦦 le 22 septembre 2020 à 14:55. Évalué à 4.
        
        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.
        
        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).
        
        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#,…).
        
        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.
        
        Et du coup ça implique quoi comme problème, vu que tu ne manipules jamais de pointeur en Java ?
        
        Les records sont entre autre là pour ça.
        
        Les licences entre openjdk et jdk d'Oracle, ne sont pas claire.
        
        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).
        
        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.
        
        10 secondes chrono si tu connais le nom de AdoptOpenJDK (qui est à connaitre si tu travailles avec Java).
        
        sur le site d'OpenJDK https://openjdk.java.net/projects/jdk8/
        
        sur le site d'adoptopenjdk https://adoptopenjdk.net/
        
        sur le site d'Oracle https://www.oracle.com/fr/java/technologies/javase-downloads.html
        
        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) le 22 septembre 2020 à 15:09. É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 🦦 le 22 septembre 2020 à 16:53. É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) le 22 septembre 2020 à 18:01. É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 🦦 le 22 septembre 2020 à 20:51. É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) le 23 septembre 2020 à 09:23. É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 le 23 septembre 2020 à 11:18. É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 🦦 le 23 septembre 2020 à 11:33. Évalué à 3.
        
        Il n'est disponible que dans les vieilles distro
        
        Si t'es pas satisfait de ta distro, ce n'est probablement pas la faute du projet upstream¹. 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 le 24 septembre 2020 à 19:12. Évalué à 6. Dernière modification le 24 septembre 2020 à 19:12.
        
        Dire que trouver un openjdk 8 est simple est faux. Il n'est disponible que dans les vieilles distro ou sur https://adoptopenjdk.net/
        
        Petit résumé de comment fonctionne l'écosystème Java:
        
        OpenJDK est un projet de développement, ie. un dépôt de code. Il ne fournit pas et n'a jamais fourni de binaires.
        
        La maintenance des branches LTS d'OpenJDK est a la charge d'un maintainer. Historiquement Oracle faisait le taff très longtemps, maintenant il passe la main à quelqu'un d'autre 6 mois après la release. En pratique on va dire qu'on s'en fiche, tout ce qu'il se passe c'est qu'il y a une branche dans le dépôt qui correspond à "Java 8 LTS" avec des tags qui sont posés régulièrement dessus.
        
        Les fournisseurs de JDK basés sur OpenJDK prennent le code de cette branche, peuvent y apporter des correctifs supplémentaire si ils le souhaitent, le compile, le test, passe le TCK et te donnent la possibilité de le télécharger.
        
        Les fournisseurs qui prennent l'upstream sans changement fournissent généralement des binaires jusqu'à la mort de la branche LTS, ca ne leur coûte virtuellement rien le taff de maintenance est fait par OpenJDK. La plupart des fournisseurs sont dans ce cas.
        
        Les fournisseurs qui maintiennent des correctifs supplémentaires, générallement liés à des contrats de support qui te garantissent qu'ils te fournissent les correctifs avant que ca soit intégré upstream choisissent d'arrêter le support d'une version quand ils veulent. C'est juste un cycle commercial.
        
        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:
        
        Azul Zulu: https://www.azul.com/downloads/zulu-community/?version=java-8-lts&architecture=x86-64-bit&package=jdk
        
        Amazon Corretto: https://docs.aws.amazon.com/corretto/latest/corretto-8-ug/downloads-list.html
        
        AdoptOpenJDK: https://adoptopenjdk.net/index.html?variant=openjdk8&jvmVariant=hotspot
        
        RedHat: https://developers.redhat.com/products/openjdk/download
        
        BellSoft: https://bell-sw.com/pages/downloads/#/java-8-lts
        
        N'importe quelle distribution correcte
        
        Je peux continuer encore
        
        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) le 24 septembre 2020 à 20:05. É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.
        
        La connaissance libre : https://zestedesavoir.com
        
        [^] # Re: C'est pas pour casser l'ambiance
        
        Posté par claudex le 25 septembre 2020 à 11:07. É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) le 25 septembre 2020 à 14:23. É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.
        
        La connaissance libre : https://zestedesavoir.com
        
        [^] # Re: C'est pas pour casser l'ambiance
        
        Posté par barmic 🦦 le 25 septembre 2020 à 14:51. É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 le 25 septembre 2020 à 14:52. É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) le 25 septembre 2020 à 16:32. É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.
        
        La connaissance libre : https://zestedesavoir.com
        
        [^] # Re: C'est pas pour casser l'ambiance
        
        Posté par ckyl le 25 septembre 2020 à 19:40. É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) le 22 septembre 2020 à 15:08. Évalué à 1.
        
        Plutôt faux depuis Java 8. On est très loin de la verbosité de Java jusqu’à 1.4 inclus.
        
        C'est encore horrible par rapport à d'autre langage (cf le nouveau record).
        
        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à
        
        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.
        
        mais un ordre de grandeur sous ce que tu donnes.
        
        Je sais, j'étais le premier surpris, c'était un serveur d'API avec connection Kafka (dépendance incluse).
        
        Et du coup ça implique quoi comme problème, vu que tu ne manipules jamais de pointeur en Java ?
        
        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.
        
        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.
        
        Tu penses à quoi ?
        
        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).
        
        J'en étais resté que JavaFX n'était plus géré. Tu penses à autres choses ?
        
        10 secondes chrono si tu connais le nom de AdoptOpenJDK (qui est à connaitre si tu travailles avec Java).
        
        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) le 22 septembre 2020 à 15:25. Évalué à 3.
        
        C'est encore horrible par rapport à d'autre langage (cf le nouveau record).
        
        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à :
        
        record Point(int x, int y) { }
        
        On ne peut pas vraiment dire que ça rends le truc illisible…
        
        Tout ce qui concerne spring boot, la gestion d'erreur complexe à comprendre, le fait que cela ne soit plus programmatique.
        
        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. ».
        
        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.
        
        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.
        
        La connaissance libre : https://zestedesavoir.com
        
        [^] # Re: C'est pas pour casser l'ambiance
        
        Posté par Nicolas Boulay (site web personnel) le 22 septembre 2020 à 16:08. Évalué à 3.
        
        Le seul truc de « verbeux » dans un record
        
        Je voulais dire que record essaye justement de palier le problème. Mais ce n'est qu'un paquet de donné.
        
        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. ».
        
        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.
        
        Les performances… Java peut monter franchement haut en performances, notamment pour un langage non compilé en natif.
        
        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 🦦 le 22 septembre 2020 à 16:58. Évalué à 6.
        
        Je sais, j'étais le premier surpris, c'était un serveur d'API avec connection Kafka (dépendance incluse).
        
        Tu as déjà vu une appli qui était grosse donc java fais de grosses appli ?
        
        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.
        
        En contrepartie tu évite la fragmentation de la mémoire et le CPU n'aime pas non plus la fragmentation mémoire.
        
        J'en étais resté que JavaFX n'était plus géré.
        
        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) le 22 septembre 2020 à 18:08. Évalué à 1.
        
        Tu as déjà vu une appli qui était grosse donc java fais de grosses appli ?
        
        Java a cette réputation, qu'un exemple confirme. Mais je serais le seul à le penser…
        
        En contrepartie tu évite la fragmentation de la mémoire et le CPU n'aime pas non plus la fragmentation mémoire.
        
        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 🦦 le 22 septembre 2020 à 20:47. Évalué à 4.
        
        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.
        
        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.
        
        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.
        
        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) le 23 septembre 2020 à 09:25. Évalué à 1.
        
        En bref ça :
        
        En contrepartie tu évite la fragmentation de la mémoire et le CPU n'aime pas non plus la fragmentation mémoire.
        
        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 le 22 septembre 2020 à 18:15. Évalué à 1.
        
        Le type 'null' est toujours là. Les types de base ne sont pas des objets.
        
        Tout ça, OK (et à mon sens le null est 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.
        
        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. :-)
        
        Les définitions mathématiques ne peuvent jamais être fausses. En effet, comme le concept est d’abord donné par la définition, il ne contient exactement que ce que la définition veut que l’on pense par ce concept. Mais, s’il ne peut rien s’y trouver de faux quant au contenu, il peut y avoir parfois, mais rarement, quelque défaut dans la forme (dans l’expression), je veux dire du côté de la précision. Ainsi cette définition ordinaire de la ligne circulaire, qu’elle est une ligne courbe dont tous les points sont également éloignés d’un point unique (du centre), a le défaut d’introduire sans nécessité la détermination courbe. En effet il doit y avoir un théorème particulier qui est dérivé de la définition, et qui peut être aisément démontré, à savoir que toute ligne dont tous les points sont également éloignés d’un point unique est courbe (qu’aucune partie n’en est droite).
        
        Kant, Critique de la raison pure.
        
        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) le 24 octobre 2020 à 16:04. É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) le 23 octobre 2020 à 17:49. Évalué à 1.
```
return swicth(c)
```
swicth -> switch
- [^] # Re: juste une coquille à corriger
  
  Posté par Benoît Sibaud (site web personnel) le 23 octobre 2020 à 18:28. Évalué à 3.
  
  Corrigé, merci.