Journal Java XII est dehors

Posté par (page perso) . Licence CC by-sa.
Tags :
32
26
mar.
2019

Ah Nal,

Je sais que les projets de ta SSII sont encore sous Java 1.6, mais il est temps de migrer: la douzième version du langage libre le plus populaire en entreprise vient de sortir.

Les nouveautés sont peu nombreuses, mais sympathiques.

Expression d'aiguillage

boolean joursOuvrees = switch (jour) {
    case LUNDI, MARDI, MERCREDI, JEUDI, VENDREDI -> true;
    case SAMEDI, DIMANCHE                -> false;
};

Unicode 11

Avec 66 nouveaux emojis 💩 et les nombres mayas pour recalculer la fin du monde.

Attention ça va déprécier chérie

Des classes et méthodes sont retirées pour alléger le JDK. N'oublie pas de rappeler à tes collègues roumains et indiens qu'il serait temps d'arrêter utiliser des classes de com.sun.*.

Openjdk 12

  • # Fin de support trop proche pour être intéressante

    Posté par . Évalué à 8.

    Dans l'administration où je suis, nos fournisseurs utilisent java 7 voir 8.

    Quand on regarde la date de fin de support de la dernière version LTS (Java 11) qui est en septembre 2026, elle fait gagner que 1an par rapport à Java 8.
    Je ne pense pas que beaucoup d'entreprise entreprendront un changement de version avec tous les tests que cela implique pour 1 année de support additionnelle.

    Il va falloir attendre la prochaine LTS pour avoir le droit à un changement chez les fournisseurs à mon avis.

  • # On se rapproche doucement des types sommes

    Posté par (page perso) . Évalué à 1. Dernière modification le 26/03/19 à 11:38.

    boolean joursOuvrees = switch (jour) {
        case LUNDI, MARDI, MERCREDI, JEUDI, VENDREDI -> true;
        case SAMEDI, DIMANCHE                -> false;
    };
    

    Reste plus qu'a définir des enums embarquant des données, et Java va devenir un vrai langage fonctionnel !

    « Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker

    • [^] # Re: On se rapproche doucement des types sommes

      Posté par . Évalué à 6. Dernière modification le 26/03/19 à 11:59.

      Attention, le plus important dans les type sum c'est d'avoir un filtrage complet dans le switch, sinon, cela peut devenir très chiant.

      "La première sécurité est la liberté"

    • [^] # Re: On se rapproche doucement des types sommes

      Posté par . Évalué à 5.

      Reste plus qu'a définir des enums embarquant des données, et Java va devenir un vrai langage fonctionnel !

      Je ne suis pas un javaiste mais à l'époque où j'en faisais encore un peu, ça existait déjà. Voir ce tutoriel et l'exemple des planètes.

    • [^] # Re: On se rapproche doucement des types sommes

      Posté par . Évalué à 2.

      Alors oui et non. Les enum ne serviront jamais à ça. Les enum sont des singletons ils ne peuvent pas servir à ça.

      Par contre les value classes sont dans les cartons et ils auront plusieurs choses : je crois qu'ils ont prévu qu'ils soient immuables, ils pourront être déconstruit et ils n'auront pas l'overhead des objets java classiques ! En terme ils devraient être plus proches des types primitifs que des descendants d'Object. Ça demande du coup à pouvoir gérer la généricité sur les types primitifs.

      Bref quelques belles choses en vue (par contre je n'ai pas vu de type algébrique).

      Il y a un talk en français de Remi Forax qui parle de tout cela : Pattern Matching en Java 10 (bon il était très optimiste sur la roadmap…)

  • # et ça marche ?

    Posté par . Évalué à -10.

    J'espère que les pavés numériques USB seront enfin utilisable sous java / Linux…

  • # JAVA : Oracle fait peur

    Posté par . Évalué à 3.

    Avec la politique commerciale d'Oracle j'ai vu des éditeurs et même des clients s'inquièter de l'avenir de Java

    Dans le peu que j'utilise openjdk remplace très bien java mais bon c'est juste pour de l'ezinstall et un peu de Elastic search.

    Mais qu'en est il du reste et de l'avenir de ce langage ?

    • [^] # Re: JAVA : Oracle fait peur

      Posté par . Évalué à 10.

      OpenJDK c'est le java vanilla.

      Maintenant oracle-java est une distribution commercial de java et pleins d'acteurs proposent leur distribution de java. RedHat et IBM évidement, mais aussi Google, Amazon et d'autres encore. Ces distributions diffèrent uniquement dans le support commercial qu'elles proposent. Elles ont pour si je ne me trompe pas une durée de support gratuit relativement courte.

      Tu as aussi adoptopenjdk qui est une distribution plus communautaire supportée par plusieurs entreprises. J'ai pas regardé la durée de son support.

      Bref ce qu'il y a c'est que maintenant OpenJDK est officiellement le seul vrai java et qu'Oracle a réduit la durée de support gratuit. Un tas d'entreprises en profitent pour faire leur propre distribution.

      J'ai pas encore compris pourquoi les gens stressent à l'idée d'utiliser une version à jour de java (c'est le cas qui permet de rester dans les supports gratuits). J'ai l'impression que c'est les même qui te disent qu'ils sont encore en Java6 et qu'ils ont planifié le passage à java 7 sorti en 2011 pour l'an prochain, que C++98 c'est pas si mal et qui ne savent pas que C11 et C18 sont sorti depuis. C'est clairement une dette technique que les gens décident soigneusement d'engranger continuellement.

      • [^] # Re: JAVA : Oracle fait peur

        Posté par . Évalué à 8.

        Bref ce qu'il y a c'est que maintenant OpenJDK est officiellement le seul vrai java

        Cette phrase a peu de sens.

        Tu gagnes le droit de t’appeler Java si tu passes le TCK qui valide que tu implémentes la spécification correctement. Le TCK est maintenant librement utilisable pour valider les implémentations dérivées d'OpenJDK.

        Le fait est que la plupart des offres commerciales récente sont majoritairement des builds d'un tag d'OpenJDK pour occuper le vide laissé par Oracle JDK et essayer de se faire de l'argent gratos. Mais l'écosystème reste bien plus divers que cela.

        J'ai pas encore compris pourquoi les gens stressent à l'idée d'utiliser une version à jour de java (c'est le cas qui permet de rester dans les supports gratuits).

        Par ce que que 99% de la planète utilise Oracle JDK / JRE qui était sous licence BCL, ie. gratos pour utilisation commerciale, ce qui n'est plus le cas.

        Par ce que personne ne comprend les licences ni n'a négocié de changement de fournisseur de JDK dans le passé. Ou pire, ils se souviennent des différences notables lors d'un switch Oracle JDK 7 vers OpenJDK 7.

        Par ce que la notion de LTS vient ajouter une variable supplémentaire (on a un journal qui nous dit de migrer à Java 12…).

        Par ce que l'offre s'est structurée au dernier moment, et même bien après la GA, avec son lot de FUD et de marketing.

        Par ce que Java 11 correspond à la première LTS depuis Java 8. Et que les gens sont donc confronté en même temps au changement de stratégie commerciale et engineering d'Oracle et aux changements techniques de Java 9 qui ne sont pas triviaux.

        Par ce que la confusion a régné jusqu'au dernier moment sur comment allait évoluer l’écosystème et l'interaction entre ses acteurs. C'est d'ailleurs toujours le cas puisque quasi personne ne contribue à jdk11u alors qu'Oracle faisait un travail de malade de maintenance et de backport auparavant (regarde https://builds.shipilev.net/backports-monitor/ et compare à la branche 8 avant qu'Oracle ne passe la main à RedHat c'est à pleurer).

        Pour avoir gérer l'ajout de Java 11 et la bascule vers un JDK 8 encore supporté dans ma boite, il y a quand même un peu de boulot pour ne pas y aller en modo YOLO et un peu de pédagogie à faire. Je reste globalement d'accord avec toi, mais si tu n'as personne en interne qui sait faire ça, on peut comprendre.

        Pour ceux qui veulent des infos factuelles, la référence est toujours là: https://docs.google.com/document/d/1nFGazvrCvHMZJgFstlbzoHjpAVwv5DEdnaBr_5pKuHo/preview

        D'un point de vu technique, l'adoption de 11 dans la plupart des stack standards commence a être relativement peu douloureuse ce qui n'était pas le cas il y a trois ou six mois. Pour les gros écosystèmes, il faudra encore 6 à 12 mois pour que ça arrive.

        • [^] # Re: JAVA : Oracle fait peur

          Posté par (page perso) . Évalué à 6.

          On peut le résumer en une phrase: les gens sont contents avec Java 8, pourquoi s'embêter à migrer?

          Incubez l'excellence sur https://linuxfr.org/board/

          • [^] # Re: JAVA : Oracle fait peur

            Posté par . Évalué à 6.

            Et d'une manière générale pourquoi changer une équipe qui gagne ?

            Dans le microcosme des ERPs : faire évoluer un produit qui fonctionne bien coute du temps et de l'argent

            et moi cela ne me choque pas d'avoir des version qui ont 9 ou 10 ans mais qui sont parfaitement stable et qui font le job alors pourquoi changer si il n'y a pas de gain quelconque ?

            Dites les moules pourquoi -3, j'ai pas compris, je transmettais quelque chose de factuel
            faut pas dire du mal de Oracle ?

  • # Java > 1.8

    Posté par . Évalué à -2. Dernière modification le 26/03/19 à 14:04.

    il est temps de migrer: la douzième version du langage libre

    Chez nous on a interdiction d'installer du jre/jdk > 8

    Visiblement l'utilisation commerciale n'est plus permise.

    On peut mettre de l'OpenJDK mais beaucoup d'applications métier veulent le jre/jdk propriétaire…

    Il est surtout temps de migrer vers un autre langage, on est quand même en 2019, ça fait 19 15 ans que ce truc aurait du crever.

    • [^] # Re: Java > 1.8

      Posté par (page perso) . Évalué à 10.

      On peut mettre de l'OpenJDK mais beaucoup d'applications métier veulent le jre/jdk propriétaire…

      Quand on code n'importe comment voilà ce qui arrive.

      Il est surtout temps de migrer vers un autre langage, on est quand même en 2019, ça fait 19 15 ans que ce truc aurait du crever.

      C'est maintenant que Java est devenu un bon langage qu'il faut migrer. L'IT est vraiment une industrie immature…

      Incubez l'excellence sur https://linuxfr.org/board/

      • [^] # Re: Java > 1.8

        Posté par . Évalué à 6.

        Yep nous on abandonne c++ alors qu'on allait passer a c++11…

        Il ne faut pas décorner les boeufs avant d'avoir semé le vent

      • [^] # Re: Java > 1.8

        Posté par . Évalué à -2. Dernière modification le 26/03/19 à 15:00.

        Quand on code n'importe comment voilà ce qui arrive.

        Pré requis éditeur, je n'y peux rien (je fais pas de dev).

        C'est maintenant que Java est devenu un bon langage qu'il faut migrer. L'IT est vraiment une industrie immature…

        A l'inverse je pourrais dire que pas mal de développeurs s'en cognent de la prod et ne comprennent pas à quel point une JVM c'est la merde. Ca bouffe un tas de ram puisque tu dois fixer un minimum/maximum, ça log comme ça veut et ça ne respecte pas les logrotate, ça n'accepte pas les signaux d’extinction, etc.

        Ah oui et la tendance naturelle à crasher au moindre pépin, par exemple sur un lag de BDD c'est vraiment génial.

        C'est vraiment la préhistoire.

        • [^] # Re: Java > 1.8

          Posté par (page perso) . Évalué à 10.

          Ca bouffe un tas de ram puisque tu dois fixer un minimum/maximum

          Ça consomme la RAM que tu lui demande. Libérer de la RAM, ça veut dire passer le GC, donc c'est consommateur, donc tant qu'on peut éviter, on évite. Pendant très longtemps les JVM ont considéré que ce que tu lui donne en max, ils peuvent le consommer sans problème, Java 12 a justement une évolution pour rendre la RAM libérée au plus vite.

          Cela dit, le vrai problème de la gestion de la RAM avec la JVM, c'est les développeurs qui confondent garbage collector avec c'est magique j'ai plus besoin de gérer la RAM, et donc qui développent des programmes qui sont en gros une fuite mémoire géante. Et qui accusent la JVM de leur propre merde ensuite.

          ça log comme ça veut et ça ne respecte pas les logrotate

          Ça loggue comme tu lui dit de logguer, et j'ai vu des tas de logrotate fonctionner nickel en production sur des JVM (4 à 11). Mais là encore ça implique que le programme à l'origine est un minimum bien conçu.

          Ah oui et la tendance naturelle à crasher au moindre pépin, par exemple sur un lag de BDD c'est vraiment génial.

          Là encore, ça dépend principalement de comment tu as codé ton application.


          En résumé, le problème de Java, c'est pas la JVM. C'est son historique dément de projets abscons, antiques, développés par des générations innombrables de prestataires mal formés et qui n'en on rien à foutre du projet, qu'on ne laisse pas s'intéresser à la façon de bien coder puisqu'il s'agit de faire survivre coute que coute un existant déjà à son dernier souffle. Les « architectes » qui n'ont jamais revu leur façon de faire depuis celles en vigueur dans les très grosses boites des années 1990 y sont aussi pour beaucoup.

          Mais c'est bien plus facile d'accuser la JVM que de se remettre en question, je suppose.

          La connaissance libre : https://zestedesavoir.com

          • [^] # Re: Java > 1.8

            Posté par . Évalué à 5.

            En résumé, le problème de Java, c'est pas la JVM. C'est son historique dément de projets abscons, antiques, développés par des générations innombrables de prestataires mal formés et qui n'en on rien à foutre du projet, qu'on ne laisse pas s'intéresser à la façon de bien coder puisqu'il s'agit de faire survivre coute que coute un existant déjà à son dernier souffle. Les « architectes » qui n'ont jamais revu leur façon de faire depuis celles en vigueur dans les très grosses boites des années 1990 y sont aussi pour beaucoup.

            C'est AMHA le même problème pour tous les langages qui ont de gros succès depuis le C ou le C++. C'est des langages simples, tu trouve des développeurs par millions. Quand tu as des millions de développeurs ils ne sont pas tous excellents, ils ne codent pas tous dans des boites qui leur permettent de faire de la qualité, là où les gens qui font du julia par exemple ils sont peu nombreux, c'est mécaniquement des gens qui s'y sont intéressés d'eux-même et qui travaillent dans des entreprises qui veulent garder leur développeurs (va trouver un nouveau développeur julia), c'est souvent des structures plus petites qui ne peuvent pas se permettre de rater un projet, etc

            • [^] # Re: Java > 1.8

              Posté par (page perso) . Évalué à 5.

              des développeurs excellents en java, j'en ai rencontré : je les compte sur les doigts d'une main
              sur les +200 que j'ai croisé, je classe le reste dans « alimentaire » : dur de trouver un bon développeur Java… limite c'est plus facile de trouver un bon développeur PHP (malgré le langage :p).

            • [^] # Re: Java > 1.8

              Posté par . Évalué à -3.

              Le problème de Java, c'est le même que celui de Basic ou de PHP : c'est très accessible au programmeur moyen. On prend un petit jeune fraîchement diplômé en France ou en Inde, et mois plus tard on le vend comme un développeur Java. Et le mec arrive réellement à faire des programmes qui semblent corrects.

              Essaie avec du C, c'est pas la même histoire : Segmentation fault et comportements erratiques aléatoires vont vite te rappeler ce que c'est qu'un langage d'homme où quand tu commets une erreur t'as pas une exception "MallocException at line 42 in foo.c" mais un appel à une fonction de la libc qui segfaulte 200 lignes plus loin…

              • [^] # Re: Java > 1.8

                Posté par . Évalué à 4.

                Un langage d'homme ?

                • [^] # Re: Java > 1.8

                  Posté par (page perso) . Évalué à 4.

                  Apparemment pour bien programmer en C, il semble nécessaire de taper au clavier non pas avec ses doigts mais avec ses testicules.

                  Ce qui m'amène deux remarques :

                  1. Comment font les transsexuels ?
                  2. Est-ce que ce n'est pas la raison de la proportion de failles de sécurité en C ?

                  La connaissance libre : https://zestedesavoir.com

                  • [^] # Re: Java > 1.8

                    Posté par . Évalué à -1.

                    Faut arrêter de faire les SJW à tout bout de champ en voyant du sexisme là où il n'y en a pas, et de ramener les bites et les couilles dans des sujets où ils n'ont pas leur place.

                    C'est hommes par opposition à gamins. Pour ceux qui ne le sauraient pas encore, la moitié des hommes sont des femmes.

                    • [^] # Re: Java > 1.8

                      Posté par (page perso) . Évalué à 2.

                      L'opposé de gamin, c'est adulte non ? Quoique quand je vois le comportement de certains « adultes » j'ai un doute (c'est une vérité générale et pas une attaque sur la personne à qui je réponds).

                      Cela dit, j'aime beaucoup l'image d'un type qui essaierait de programmer en C uniquement à l'aide de ses attributs. Ça doit vite être complexe quand il faut utiliser des combinaisons de touches.

                      Et douloureux.

                      Il y a un équivalent du BÉPO optimisé pour couilles ?

                      La connaissance libre : https://zestedesavoir.com

              • [^] # Re: Java > 1.8

                Posté par (page perso) . Évalué à 5.

                Le C c'est un peu la Messe en latin de la programmation?

                Incubez l'excellence sur https://linuxfr.org/board/

          • [^] # Re: Java > 1.8

            Posté par . Évalué à 6.

            En résumé, le problème de PHP, […] C'est son historique dément de projets abscons, antiques, développés par des générations innombrables de prestataires mal formés et qui n'en on rien à foutre du projet, qu'on ne laisse pas s'intéresser à la façon de bien coder puisqu'il s'agit de faire survivre coute que coute un existant déjà à son dernier souffle.

            Je jurerais avoir déjà lu cette phrase. Comme quoi, après quelques années et malgré leurs améliorations, tous les langages "phare" reçoivent les mêmes reproches… D'ici 5 ans (je suis large) on lira la même phrase avec JS (ou Python ?) et dans 10 ans ça sera le tour de Go.

            • [^] # Re: Java > 1.8

              Posté par (page perso) . Évalué à 4.

              C'est assez vrai. Dans le cas de Java, l'effet est renforcé par :

              • L'historique du langage (fonctionnalités arrivées tard) que certains n'ont toujours pas intégrés (en réalité / dans leurs reproches)
              • Un langage (et un moteur d'exécution) qui comporte plus de subtilités qu'on pourrait le croire (comme la gestion mémoire), ou dont le fonctionnement change avec le temps (le garbage collector / le compilateur JIT)
              • Le fait que c'est un langage orienté Entreprise™ avec tout ce que ça implique comme :
              • Les conceptions antiques
              • Les équipes ultra-morcelées avec des gens qui bossent 3 mois sur un tout petit bout du code
              • Les projets très longs et très chers donc impossibles à refacto / réécrire
              • La faiblesse de la communauté open-source et de l'outillage qui peut arriver avec (ne serait-ce que des règles aussi idiotes qu'un formatage du code par défaut)

              PHP me donnait plus l'impression de poser problème à cause de failles intrinsèques au langage (PHP 4 était une jolie collection d'incohérences) ; JS plus à cause de sa communauté et de son mode de fonctionnement ultra-éclaté.

              La connaissance libre : https://zestedesavoir.com

              • [^] # Re: Java > 1.8

                Posté par (page perso) . Évalué à 5.

                La faiblesse de la communauté open-source et de l'outillage qui peut arriver avec (ne serait-ce que des règles aussi idiotes qu'un formatage du code par défaut)

                Je suis globalement bien d'accord avec ton commentaire, mais au contraire sur ce point je ne vois pas comment tu peux dire ça. Tu as une tétrachiée de bibliothèques / cadriciels opensource pour faire quasiment tout, des outils de "qualité" en veux-tu en voilà (notamment pour pondre des métriques pour les Enterprise)…

              • [^] # Re: Java > 1.8

                Posté par . Évalué à 3.

                • L'historique du langage (fonctionnalités arrivées tard) que certains n'ont toujours pas intégrés (en réalité / dans leurs reproches)
                • Un langage (et un moteur d'exécution) qui comporte plus de subtilités qu'on pourrait le croire (comme la gestion mémoire), ou dont le fonctionnement change avec le temps (le garbage collector / le compilateur JIT)

                C'est pas le cas de PHP ? Les classes de PHP ont beaucoup évoluées avec le temps. Le transtypages de PHP est très subtile.

                • Les projets très longs et très chers donc impossibles à refacto / réécrire

                facebook a trouvé plus facile de réécrire plusieurs le moteur PHP que de réécrire facebook…

                • La faiblesse de la communauté open-source et de l'outillage qui peut arriver avec (ne serait-ce que des règles aussi idiotes qu'un formatage du code par défaut)

                Ça c'est une mauvaise connaissance de ta part à mon avis. Outre le fait que le moteur principal soit open source, si on critiquait maven (qui est open source) parce qu'il téléchargeait « la moitié de l'Internet » il n'a jamais téléchargé autre chose que du code open source… Tu as 2 fondations qui ne font que de l'open source et qui hébergent presque que des projets de l'écosystème java (eclipse et apache). Rien que la contribution de Red Hat au monde java open source est assez immense.

          • [^] # Re: Java > 1.8

            Posté par . Évalué à 0.

            Ça consomme la RAM que tu lui demande.

            C'est ultra commun de mettre du Xmx à 4G voire plus sur des applications métier, sous peine de refus de démarrer. Sous PHP aussi il y a une limite de mémoire, mais je n'ai jamais vu une appli utiliser autant de ram…

            Ça loggue comme tu lui dit de logguer, et j'ai vu des tas de logrotate fonctionner nickel en production sur des JVM (4 à 11). Mais là encore ça implique que le programme à l'origine est un minimum bien conçu.

            Si tu essaie de faire tourner un log avec logrotate, la JVM va continuer d'écrire dans l'ancien. Il faut alors confier à java la rotation (ce que je trouve pas pratique et pas normal) et ensuite coder des crons dégueux pour faire des find qui compressent et suppriment les anciens fichiers.

            Je ne connais pas tous les middlewares du monde, mais je n'en vois que deux qui font ça: Java et MongoDB. Ce dernier ayant au moins une option pour permettre l'utilisation propre de logrotate.

            En résumé, le problème de Java, c'est pas la JVM. C'est son historique dément de projets abscons, antiques, développés par des générations innombrables de prestataires mal formés et qui n'en on rien à foutre du projet, qu'on ne laisse pas s'intéresser à la façon de bien coder puisqu'il s'agit de faire survivre coute que coute un existant déjà à son dernier souffle. Les « architectes » qui n'ont jamais revu leur façon de faire depuis celles en vigueur dans les très grosses boites des années 1990 y sont aussi pour beaucoup.

            La seule chose que j'ai à dire face à ça: ça ne le fait pas avec les autres langages. Je pense qu'il existe un historique très important de bidules en PHP, et pourtant ça tourne sur des serveurs beaucoup plus petits, ça ne fait pas crasher Apache (ou php-fpm) au moindre pépin, on y colle du logrotate sans problèmes. Ah oui et ça démarre instantanément, pas comme les JVM/JBoss/Wildfly où tu attends parfois 1 minute que ton appli démarre, génial quand tu veux automatiser et que tu dois coder plein de check à chaque étape de ton playbook pour attendre.

            • [^] # Re: Java > 1.8

              Posté par . Évalué à 6.

              Si tu essaie de faire tourner un log avec logrotate, la JVM va continuer d'écrire dans l'ancien. Il faut alors confier à java la rotation (ce que je trouve pas pratique et pas normal) et ensuite coder des crons dégueux pour faire des find qui compressent et suppriment les anciens fichiers.

              log4j et logback peuvent discuter avec syslog, c'est ce que j'utilise perso. Tu as eu un problème avec ? Les 2 se configurent via un fichier que tu peux forcer au démarrage de l'appli.

              Pour les temps de démarrage, je n'ai jamais pu le constater sauf en première installation avec un jdk configuré pour utiliser /dev/random à la place de /dev/urandom.

              Mais globalement c'est bizarre de voir les gens reprocher tout à la JVM. Les équipes d'Elastic font comment pour sortir elasticsearch ? De la magie noire ?

        • [^] # Re: Java > 1.8

          Posté par (page perso) . Évalué à 3.

          PS : les prérequis éditeurs, par contre c'est une vraie plaie. Dédicace à IBM qui vends des logiciels Java qui ne fonctionnent que sur une JVM IBM (J9, maintenant libéré sous le nom OpenJ9 et propriétés de la fondation Eclipse). Mais c'est généralement des limitations arbitraires.

          La connaissance libre : https://zestedesavoir.com

        • [^] # Re: Java > 1.8

          Posté par (page perso) . Évalué à 4.

          Tu n'aimes pas la JVM? Ca tombe bien le futur de Java sera compilé en natif: https://www.graalvm.org/

          Incubez l'excellence sur https://linuxfr.org/board/

    • [^] # Re: Java > 1.8

      Posté par . Évalué à 3.

      On peut mettre de l'OpenJDK mais beaucoup d'applications métier veulent le jre/jdk propriétaire…

      Oracle JDK est une distribution qui est identique à OpenJDK (le monde de JRockit est terminé depuis un certain temps).

      • [^] # Re: Java > 1.8

        Posté par (page perso) . Évalué à 2. Dernière modification le 26/03/19 à 15:43.

        Pas exactement non. Sinon comment expliquer que Minecraft soit plus véloce sous Oracle JDK que sous OpenJDK dans ce cas ?

        C'est globalement identique mais Oracle JDK apporte un peu de cosmétique et de nouveaux packages. Et évidemment, la licence n'est pas la même…

        A une époque, la JVM n'était pas la même non plus. Je crois que depuis JDK10 elles sont de nouveau identiques (à confirmer, je ne suis pas certain de la version).

        Allez, je retourne sur mon JDK6 :D (au passage, j'aime beaucoup l'expression d'aiguillage, je la trouve très sexy en l'état).

        La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

        • [^] # Re: Java > 1.8

          Posté par . Évalué à 2.

          Pas exactement non. Sinon comment expliquer que Minecraft soit plus véloce sous Oracle JDK que sous OpenJDK dans ce cas ?

          Source ?

    • [^] # Re: Java > 1.8

      Posté par . Évalué à 3.

      ça fait 19 15 ans que ce truc aurait du crever

      En admettant que tu n'aimes pas le langage, la technologie VM est très présente.
      La JVM est une bonne VM.
      Et elle permet énormément de langages : clojure, kotlin, scala, etc.

  • # Ne pas utiliser en prod...

    Posté par . Évalué à 2.

    mais il est temps de migrer: la douzième version du langage libre le plus populaire en entreprise vient de sortir.

    Heu non, tu ferais bien mieux d'attendre la prochaine LTS.

    Personne n'utilise de non LTS en production. Les releases intermédiaires servent juste pour se forcer à faire de petits incréments et à les évaluer les changements. Mais vu que presque personne ne les utilisent la force de la boucle de feedback est limité…

    • [^] # Re: Ne pas utiliser en prod...

      Posté par . Évalué à 2.

      Dans ce cas là n'utilise pas non plus Java11 les derniers chiffres que j'ai vu parlaient de moins de 10% d'utilisation. Sauf que le support gratuit de Java8 pour un usage commercial s'est terminé il y a 2 mois.

      Elles font quoi les entreprises sérieuses pleines de gens en cravaté qui font des choses sérieuses ?

      • [^] # Re: Ne pas utiliser en prod...

        Posté par (page perso) . Évalué à 4. Dernière modification le 26/03/19 à 15:47.

        Elles font quoi les entreprises sérieuses pleines de gens en cravaté qui font des choses sérieuses ?

        Elles sont toujours sous JDK 6/7/8 (enfin je parle pour mon cas).

        Nous sommes un gros éditeur logiciel à destination du monde de la finance et on accumule de la dette technique parce que les clients ne font pas évoluer leur infra… Ils sont très frileux à ce niveau-là…

        Bon, pour être un peu plus moderne, on migre doucement sous Angular. Mais on livre un binaire compilé en JDK 6/7/8 malgré tout :p.

        La majeure partie des morts l'était déjà de son vivant et le jour venu, ils n'ont pas senti la différence.

        • [^] # Re: Ne pas utiliser en prod...

          Posté par (page perso) . Évalué à 4. Dernière modification le 26/03/19 à 21:41.

          parce que les clients ne font pas évoluer leur infra… Ils sont très frileux à ce niveau-là…

          ajoute java 1.4.2 à ta liste, j'en ai un sous le coude là… si, si, on est en 2019 :p

          par contre, c'est bien d'avoir les commerciaux Oracle :

          • faut payer pour toute la ferme de virtualisation, même s'il n'y a qu'une seul VM qui l'utilise ; voyons $300 x 2000 cœurs what a bargain ! o_O
          • si on achète leur support « bon marché », bin faut payer aussi pour les java 6 et 7 déployés (mais sans màj proposée), des fois qu'on pose des questions, histoire de contaminer les applis pas virtualisées, bravo /o\

          sérieux, qui a déjà appelé du support à java ?! Weblogic ou WAS, oui éventuellement…

          Heureusement que AdoptOpenJDK 8 a peu de régressions sur l'Oracle JDK 8 côté serveur, la migration sera plus simple si jamais il y a une CVE 0-day en avril :-) Dire que Mark Reihnold a lancé ce travail dès le JDK6 et que même avec JDK11 il reste des choses à remplacer : https://adoptopenjdk.net/MigratingtoAdoptOpenJDKfromOracleJava.pdf?variant=openjdk11&jvmVariant=hotspot (coming soon o_O)

          Pour le poste de travail, oublier JNLP va être compliqué :/

      • [^] # Re: Ne pas utiliser en prod...

        Posté par . Évalué à 9.

        Dans ce cas là n'utilise pas non plus Java11 les derniers chiffres que j'ai vu parlaient de moins de 10% d'utilisation

        Ça na rien à voir.

        Java 11 est une LTS dont la maintenance est pour le moment annoncée jusqu'à fin 2024.

        Java 12 est une release qui ne verra plus aucune mise à jour dans moins de 6 mois. Le jour ou il y a un CVE ouvert et que tu rends compte que tes dépendances t'empêchent de basculer sur la dernière release t'es mort.

        L’écosystème a actuellement du mal à suivre ce rythme. Rien que pour Java 11 j'ai du patcher 4 dépendances, dont Maven, pour faire tourner des projets simples 2 mois après la GA… Même si l'écosystème suivait, virtuellement aucune entreprise ayant plus d'une webapp n'arrive à tenir le rythme de tout mettre à jour tous les 6 mois.

        Sauf que le support gratuit de Java8 pour un usage commercial s'est terminé il y a 2 mois.

        Tu n'as jamais eu de support gratuit de Java 8. Tu avais un Oracle JDK 8 sous BCL, permettant une utilisation commerciale gratuite sans support, qui est passée en statut end of public updates il y a deux mois. Il n'y aura donc plus de mise à jour.

        Pour les gens utilisant Oracle JDK 8 tu as donc le choix entre garder une version sans mise à jour possible en cas de CVE, prendre un contrat de support ou migrer vers OpenJDK 8 qui n'est pas à équivalence fonctionnelle contrairement à OpenJDK 11 VS Oracle JDK 11. Potentiellement plus problématique donc mais si la plupart des problèmes sont surmontables.

        Elles font quoi les entreprises sérieuses pleines de gens en cravaté qui font des choses sérieuses ?

        Elles devraient chercher un fournisseur de JDK 11 qui correspond à leur besoin ET chercher un nouveau fournisseur de JDK 8 ou prendre un contrat de support pour les applications impossibles à migrer en Java 11 actuellement.

        Migrer sur du 12, ie. non LTS, sauf cas très spécifique, c'est franchement une mauvaise idée.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.