Journal Java 9 est dehors

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
43
22
sept.
2017

Bonjour Nal,

Je t’écris pour t’informer de la sortie de la nouvelle et très attendue version majeure de Java, l’une des plus grosses plates‐formes de développement du marché. Voici un petit tour des nouveautés :

Titre de l’image

Victime de jmod

La principale nouveauté est l’introduction d’un système de modules. Ce système mérite un journal complet, mais le principal apport sera le « debloat » (un peu) de l’environnement d’exécution et des applications Java.

Dans les poèmes de jshell

Un outil jshell permet de jouer avec le langage en ligne de commande et utiliser le langage pour faire du script : pratique pour remplacer des scripts Shell ou Python !

    jshell> double PI = 3.1415926535
    PI ==> 3.1415926535
    |  created variable PI : double

    jshell> volume(2)
    |  attempted to call method volume(double) which cannot be invoked until method cube(double) is declared

    jshell> double cube(double x) { return x * x * x; }
    |  created method cube(double)
    |    update modified method volume(double)

    jshell> volume(2)
    $5 ==> 33.510321637333334
    |  created scratch variable $5 : double

Applet mon numéro

Une excellente nouvelle : le greffon Java pour navigateur va rejoindre Flash et Silverlight dans le purgatoire des technologies pénibles.

What string color

Les chaînes de caractères prendront moins de place en mémoire si elles contiennent des caractères latin 1.

Ramasse‐miettes, chouette, c’est sympa

G1 sera désormais le ramasse‐miettes par défaut. L’idée est de privilégier la faible latence. Des impacts sont à prévoir sur les applications en production : il faudra faire des tests sérieux pour voir s’il y a un gain ou perte, chaque application ayant des besoins et des objectifs différents.

Trololog

Une nouvelle API de journalisation minimaliste a été ajoutée. Je n’ai pas compris pourquoi ce changement, l’API actuelle n’étant pas bien compliquée.

UTF-8 vaincra

Les fichiers *.properties pourront enfin être écrits en UTF-8. Ces fichiers, souvent utilisés pour l’internationalisation, étaient limités à l’ISO-8859-1 (latin 1)…

Autres changements

  • les chauves seront contents d’apprendre l’ajout d’une API pour manipuler des TIFF ;
  • la gestion des hautes résolutions (HiDPI) permettra de ne plus saigner des yeux sous GNU/Linux et Windows ;
  • GTK 3 est enfin géré, il faudra toutefois l’activer via la propriété jdk.gtk.version.

  • # Dépêche ?

    Posté par  (site web personnel) . Évalué à 6.

    Ce nourjal mériterait une dépêche.

    • [^] # Re: Dépêche ?

      Posté par  . Évalué à 4.

      M'enfin, j'ai même pas appris si l'implémentation libre de Java suit vers cette version 9 ou pas?

      ⚓ À g'Auch TOUTE! http://afdgauch.online.fr

      • [^] # Re: Dépêche ?

        Posté par  . Évalué à 5.

        http://openjdk.java.net/projects/jdk9/

      • [^] # Re: Dépêche ?

        Posté par  . Évalué à 6.

        C'est l'implémentation de référence, donc oui, ça suit.

        « 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: Dépêche ?

          Posté par  (site web personnel) . Évalué à 3.

          ça suit, donc oui, C'est l'implémentation de référence.

          ça précède, non ? Selon le principe du « _release early, release often _»

          Me gourre-je ?

          • [^] # Re: Dépêche ?

            Posté par  . Évalué à 5.

            Me gourre-je ?

            Oui. C'est « me gourré-je », me semble-t-il ;)

    • [^] # Re: Dépêche ?

      Posté par  . Évalué à 8.

      Clairement !

      Mais il faudrait sans doute compléter un peu. La liste complète des nouveautés est ici.

      Dans les nouveautés sympathiques (non citées dans le journal), je vois aussi :
      - les méthodes privées dans les interfaces (pour partager le code entre méthodes default ou static)
      - les fabriques statiques pour les collections immuables : Set.of(…), List.of(…), Map.of(…)
      - implémentation de Reactive Streams (classe Flow)

      Bon bien sûr, tout le monde ne s'intéresse pas aux mêmes fonctionnalités !

      • [^] # Re: Dépêche ?

        Posté par  . Évalué à 5.

        • les fabriques statiques pour les collections immuables : Set.of(…), List.of(…), Map.of(…)

        Enfin!

  • # Latin-1 :'(

    Posté par  (site web personnel, Mastodon) . Évalué à 3.

    C'est triste de voir des strings en Latin-1 plutôt qu'en UTF-8 qui aurait fait ganger à peu près autant de place.

    Pour le logging, apparament le but est d'avoir un support pour les logs directement dans le coeur de Java, afin d'éviter que tous les autres modules (ou presque) dépendent de java.util.logging.

    • [^] # Re: Latin-1 :'(

      Posté par  (site web personnel, Mastodon) . Évalué à 5.

      C'est une question de performances je suppose : UTF-8 utilise des caractères qui n'ont pas tous la même longueur (en octets), ce qui complexifie pas mal les traitements.

      La connaissance libre : https://zestedesavoir.com

    • [^] # Re: Latin-1 :'(

      Posté par  (site web personnel) . Évalué à 1.

      Avant UTF-16, maintenant UTF-8, non ? du moins c'est ce que j'en déduis..

      • [^] # Re: Latin-1 :'(

        Posté par  (Mastodon) . Évalué à 4.

        Non, pas du tout. En fait, avant, tout était codé en UTF-16. Maintenant, un objet String contient un nouveau champ qui précise l'encodage utilisé. Ça va être latin1 si possible, ou UTF-16 sinon. Pour le développeur, ça ne devrait rien changer, c'est un détail d'implémentation et l'API publique ne change pas.

    • [^] # Re: Latin-1 :'(

      Posté par  . Évalué à -1.

      Je trouve surtout triste de voir implémentée une solution qui pour faire économiser de la mémoire aux pays anglophones va faire perdre de la mémoire à tous les pays qui n'ont pas leur alphabet entier dans Latin-1. Les compagnies de haute technologie ont beau être majoritairement américaine, je trouve tout ça très regrettable. Alors oui, ça n'est qu'un flag par chaîne de caractères, mais sur des milliards de chaînes de caractères, ça fait beaucoup de gâchis.
      Désolé, votre alphabet est un alphabet de seconde zone, revenez plus tard.

      • [^] # Re: Latin-1 :'(

        Posté par  (Mastodon) . Évalué à 4.

        Les strings, ça ne sert pas qu'à afficher du texte à destination de l'utilisateur, et donc, même pour une application affichée en chinois (par exemple), il y aura probablement beaucoup de chaines de caractères qui sont codables en latin1 : requêtes SQL, chemins vers des fichiers, URLs, messages pour les logs, etc.

        Au final, on gagnera de la place sur tout ça, et ça risque bien de largement contrebalancer le fait qu'on doive stocker un flag supplémentaire sur chaque objet string.

    • [^] # Re: Latin-1 :'(

      Posté par  (site web personnel) . Évalué à 3.

      CPython a implémenté une optimisation similaire dans Python 3.3:
      https://www.python.org/dev/peps/pep-0393/

      Si une chaîne ne contient que des caractères dans U+0000-U+00FF ("Latin1") : 1 octet par caractère. Que dans U+0000-U+FFFF ("BMP") : 2 octets par caractères. Sinon ("Astral"), 4 octets par caractère (désolé pour vos jolis emojis). Du coup, "toto" prend 4 octets au lieu de 16 avec Python 2 (en ignorant les entêtes des objets).

      • [^] # Re: Latin-1 :'(

        Posté par  . Évalué à 1.

        En Python 2 "toto" prend 4 octets, tu confonds avec u"toto" ;-)

  • # AH ah ah ...

    Posté par  (site web personnel) . Évalué à 10.

    Bon c'est dredi on se lâche un peu :

    Un outil jshell permets de jouer avec le langage en ligne de commande et utiliser le langage pour faire du scripting: pratique pour remplacer des scripts shell ou python!

    Bon courage :)

    • [^] # Re: AH ah ah ...

      Posté par  . Évalué à 2.

      bah en fait ils introduisent aussi de la compilation ahead of time, donc si tu fais un script java, tu compile, et ça démarre très vite (ce qui a souvent été le problème du scripting en java).

      rien à voir avec jshell ceci dit :)

      • [^] # Re: AH ah ah ...

        Posté par  (site web personnel) . Évalué à 3.

        Je n'ai rien contre Java (ou presque … trop de machine virtuelle 1.6 1.7 1.8)
        C'est un excellent langage mondialement reconnu avec des librairies et des outils exceptionnels, j’espère avoir compris ce que sont : TOMCAT / JBOSS / HIBERNATE / ElasticSearch

        mais

        pour remplacer des scripts shell ou python!

        honnêtement j'ai du mal à le croire, Java est toujours "fortement typé" non … ou il a plus évolué que ce je croyais …

        Attention je dis pas que c'est impossible, mais difficile à croire quand on connais le shell et python et un peu java
        A mon humble avis … of course

        • [^] # Re: AH ah ah ...

          Posté par  . Évalué à 4.

          Quel est selon toi la contrainte à faire un langage de script avec un langage fortement typé ?

          • [^] # Re: AH ah ah ...

            Posté par  (site web personnel) . Évalué à 5.

            Par expérience :

            Les cas sont rares ou il y a besoin de typage en shell, je stocke généralement des chaînes, nom de de fichiers le plus souvent
            des chemins ou listes de chaînes

            d'ailleurs des qu'il faut calculer ( un entier, une date etc …) je bascule en python, ou qu'il faut soigner une présentation comme un rapport de sauvegarde par mail

            Il est vrai que je scripte du shell "portable" une vieille habitude de l'époque ou il y avait plusieurs Unix en circulation.
            parfois on m'a imposer du ksh et c'est plus facile.

            Et parfois certaines "applications" mélangent script shell + langage plus évolué comme Perl ou Python

            Et quand je dis application il s'agit de lire un fichier de vérifier un format, d'en extraire certaines données de le transférer sur un autre serveur, de générer du SQL et de l'injecter dans une base de données puis d'envoyer un compte rendu et un mail pour prévenir.

            C'est possible de faire la même chose en java complètement ou partiellement c'est sur, mais certaines formes d'écriture en shell sont tellement pratique et efficace qu'il serait dommage de s'en passer

            ex : [ -d $REP ] || mkdir $REP # l'équivalent java (idem python / perl) doit prendre un peu plus de lignes :)

            Autre exemple découvert dernièrement :

            timeout 5h synchro.sh

            Si le script synchro.sh met plus de 5h alors il sera "killer"

            pratique pour effectuer des synchronisation partielle en automatique

            Certains outils sont tellement pratique et efficace qu'il est dommage de ne pas les apprendre

            Ainsi j'aimerais savoir quel est l'équivalent python de JBOSS et HIBERNATE en aussi abouti

            • [^] # Re: AH ah ah ...

              Posté par  . Évalué à 2.

              ex : [ -d $REP ] || mkdir $REP # l'équivalent java (idem python / perl) doit prendre un peu plus de lignes :)

              Pour python du moins, pas vraiment. C'est peut être un poil moins rapide/intuitif par contre.

              os.path.isdir(d) or os.mkdir(d)

              • [^] # Re: AH ah ah ...

                Posté par  (site web personnel) . Évalué à 5.

                Pour python le code exact serait plutot :

                import os
                d = 'toto'
                os.path.isdir(d) or os.mkdir(d)

                En shell :

                REP=toto
                [ -d $REP ] || mkdir $REP

                Si tu pouvais compléter en java vu mon niveau cela me prendrais trop longtemps (stp ne serait ce que pour ma culture personnelle)

                Ensuite je veux récupérer le premier argument de la ligne de commande

                en shell :
                REP=$1
                [ -d $REP ] || mkdir $REP

                cela risque de rajouter pas mal de choses en python comme en java, mais c'est normal
                ces langages n'ont pas le même usage.

                python comme java nécessite plus de réflexion préalable avant de pondre un traitement qui tourne
                le shell est parfait dans son rôle de "glue" et par son universalité et sa disponibilité.

                J'ai des scripts shell écrit au siècle dernier qui tourne encore cela risque d'être moins vrai pour python et java
                mais ces langages font un peu plus de chose que ce vénérable sh

                IL est vrai que je faisais déjà du shell avant les premières versions de java et de python

                Et dans son rôle le shell sera difficile à déboulonner, même M$ l’intègre sur ses OS :) (ok c'est pas un référence)

                Pour finir une petite touche de méchanceté gratuite et assumée (l'apanage des sysadmins :) )
                sur une machine devant tourner 24/24 7/7 tu préféres : 10 scripts java ou 10 scripts shell …

                • [^] # Re: AH ah ah ...

                  Posté par  . Évalué à 3.

                  cela risque de rajouter pas mal de choses en python comme en java, mais c'est normal
                  ces langages n'ont pas le même usage.

                  En python, pas vraiment, c'est très simple:

                  import sys
import os

rep = sys.argv[1]
os.path.isdir(rep) or os.mkdir(rep)

                  Je dirais même qu'au contraire, on gagne en ligne des qu'on dépasse le cas très simple. Par exemple, on peut tester si une option est passée en argument sans devoir se soucier de l'ordre des arguments: 

                  if "--my-arg-1" in sys.argv:
  action_1()

                • [^] # Re: AH ah ah ...

                  Posté par  (site web personnel) . Évalué à 6.

                  Pour finir une petite touche de méchanceté gratuite et assumée (l'apanage des sysadmins :) )
                  sur une machine devant tourner 24/24 7/7 tu préféres : 10 scripts java ou 10 scripts shell …

                  Si tu dois tourner 24/7 désolé mais Java (et encore mieux Scala, mais bon je reste dans tes choix).
                  Plus le typage est fort moins tu as de risque de surprise à l'éxecution, donc shell est presque le pire choix.

            • [^] # Re: AH ah ah ...

              Posté par  (site web personnel) . Évalué à 3.

              ex : [ -d $REP ] || mkdir $REP # l'équivalent java (idem python / perl) doit prendre un peu plus de lignes :)

              new java.io.File(rep).mkdir()

              De rien.

              P.S. : il se passe quoi avec ton code si REP contient un espace ?

              • [^] # Re: AH ah ah ...

                Posté par  (site web personnel) . Évalué à 4.

                Bon faut être honnête ça fait pas exactement pareil (ça crée le dossier mais s'il existait déjà ça renvoie false). Là c'est bon :

                File f = new File(rep); f.isDirectory() || f.mkdir()

            • [^] # Re: AH ah ah ...

              Posté par  . Évalué à 4.

              Après c'est quand même beaucoup une question de goût, et surtout d'expérience.

              Quand je lis ça :

              [ -d $REP ] || mkdir $REP

              Je me dis : OK, je vais créer un répertoire, mais c'est quoi le truc avant ? Ah oui, la syntaxe shell permet de "tester" en utilisant une syntaxe qui fait penser à un argument (le "-p"). Évident pour celui qui fait du shell depuis 15 ans, cryptique pour celui qui en fait peu ou prou.

              En bon développeur java, le code code java correspondant (comme celui fourni par Sufllope plus bas) me semble infiniment plus clair, et donc plus maintenable.

              Et puis, $REP c'est quoi ? Une simple chaîne, ou une liste de fichiers/répertoires ? Et comment se comporte mkdir si tu lui passes plusieurs répertoires ? Tout ça, un expert shell va le savoir sans avoir besoin d'aller consulter man ; là où un développeur java va préférer itérer sur une liste et tester pour chaque répertoire ce qui se passe, et comment se comporter en cas d'erreur.

              Alors, comme dit également plus bas, java n'a pas été pensé pour l'écriture rapide de scripts. Mais en ce qui me concerne, l'écriture rapide de script est souvent une mauvaise solution à un problème. Mauvaise solution qui peut quand même être la meilleure par manque de temps, du coup je sais quand même faire du shell…

              • [^] # Re: AH ah ah ...

                Posté par  (site web personnel) . Évalué à 8.

                Vous savez quoi … vous m'avez convaincu que l'informatique a évolué …
                je ne vais pas scripter en java, mais j'ai compris que c'était possible, et pas qu'en java d'ailleurs …

                Bon je vais de ce pas rejoindre le mouvement de libération des vieux de Huguette et Raymond …

              • [^] # Re: AH ah ah ...

                Posté par  . Évalué à 3. Dernière modification le 01 octobre 2017 à 14:29.

                [ -d $REP ] || mkdir $REP

                Je ne comprends pas la différence (fonctionnelle) que ça peut faire avec un simple mkdir $REP ?

                Il faudrait effectivement mettre des guillemets doubles autour de $REP, c’est une chaîne, pas un entier, donc la valeur peut inclure des espaces et il faut dans ce cas éviter qu’elle soit splittée en N tokens…

                Sinon moi aussi en shell je préfère écrire des trucs comme : [ … ] && … ou [ … ] || …, en regroupant éventuellement à l’aide d’accolades, plutôt qu’utiliser le mot clé if, c’est juste une question de concision. Ce n’est en rien cryptique. On peut également utiliser la commande test implicitement (à la place du crochet ouvrant) c’est tout aussi limpide.

                Et puis, $REP c'est quoi ? Une simple chaîne, ou une liste de fichiers/répertoires ?

                J’aurais appelé la variable $REPS si c’était une liste (aka "tableau" en shell) :) Je fais d’ailleurs pareil en Python, une variable « au pluriel », c’est une liste (ou un set, bref, un itérable…), je trouve ça plus plaisant que préfixer chaque variable avec son type : l_truc, i_machin, etc… (ou je sais ma méthode présente des inconvénients, pour les cas équivoques j’utilise le préfixage ou bien je trouve un synonyme qui termine pas par un s au singulier…)

                Et comment se comporte mkdir si tu lui passes plusieurs répertoires ? Tout ça, un expert shell va le savoir sans avoir besoin d'aller consulter man ;

                Un expert ? Si tu sais pas comment se comporte mkdir avec plusieurs arguments je dirais que tu n’as même pas le niveau basique pour utiliser un shell *NIX, tu devrais même pas avoir à relire les scripts de quelqu’un d’autre, non ?

                Et puis… Je ne suis ni un expert ni un débutant, la commande man je l’utilise sans retenu, je vois vraiment pas pourquoi je devrais me farcir la mémoire avec toutes les options de toutes les commandes… et souvent j’ouvre le man simplement pour vérifier que ma mémoire est bonne…

                là où un développeur java va préférer itérer sur une liste et tester pour chaque répertoire ce qui se passe, et comment se comporter en cas d'erreur.

                C’est tout a fait possible en shell, comme avec n’importe quel langage, c’est en rien une obligation d’appeler une seule fois mkdir _o_

                En Java aussi je suppose que tu as le choix entre itérer sur la liste ou bien passer la liste directement à la fonction de base (built-in) qui crée les répertoires.

                • [^] # Re: AH ah ah ...

                  Posté par  . Évalué à 2.

                  [ -d $REP ] || mkdir $REP
                  Je ne comprends pas la différence (fonctionnelle) que ça peut faire avec un simple mkdir $REP ?

                  Dans pas mal de cas on s'en fiche. Mais si on écrit des scripts qui tiennent la route ça pose problème.

                  Ca évite l'affichage d'un message d'erreur.
                  On peut remplacer par mkdir "$REP" >/dev/null mais ce n'est pas mieux.

                  Et ça évite de générer un code de retour !=0 (utile par exemple si le script contient set -o errexit
                  On peut remplacer par mkdir "$REP" || true mais pareil, ce n'est pas mieux.

                  Si on veut la totale ça fait mkdir "$REP" >/dev/null || true

            • [^] # Re: AH ah ah ...

              Posté par  (site web personnel) . Évalué à 4.

              [ -d $REP ] || mkdir $REP

              Je sais que c'est pas le sujet mais, c'est quoi l'intérêt par rapport à un mkdir -p $REP ?

              • [^] # Re: AH ah ah ...

                Posté par  (site web personnel, Mastodon) . Évalué à 5.

                ça ne crée pas les dossiers parents s'ils n'existent pas.

                • [^] # Re: AH ah ah ...

                  Posté par  . Évalué à 3.

                  Je dois pas être bien réveillé mais je comprends pas la différence avec un simple mkdir $REP qui ne créera pas non plus les parents (et qui ne fera rien si $REP est déjà un répertoire) ?!

                  Si $REP est un fichier (pas répertoire) existant il n’y a, sauf erreur, pas de différence non plus : le mkdir créera rien du tout.

                  Quelqu’un pour m’expliquer ?

                  • [^] # Re: AH ah ah ...

                    Posté par  . Évalué à 2.

                    Si le fichier existe déjà (que ce soit un répertoire ou pas), mkdir échouera (code de retour > 0) avec un message d'erreur, ce n'est pas la même chose que ne rien faire.

                    • [^] # Re: AH ah ah ...

                      Posté par  . Évalué à 3.

                      Oui ok…

                      Ce n’est pas la même chose mais le résultat sera le même, avec en plus, l’information que le répertoire existe déjà indiquée sur stderr :)

                      Bon, c’est vrai que si le fait que le répertoire existe déjà n’est pas une erreur on peut justement souhaiter ne rien avoir sur stderr…

                      Merci pour ta réponse.

                      • [^] # Re: AH ah ah ...

                        Posté par  . Évalué à 2.

                        Il n'y a pas que ça, si on a activé dans le script l'option set -e, alors si le mkdir échoue le script s'arrête là.
                        Et même sans ça, si on est dans une fonction et que le mkdir est la dernière commande de la fonction, alors son code de retour devient le code de retour de la fonction, ce qui n'est peut-être pas ce qu'on voulait.

              • [^] # Re: AH ah ah ...

                Posté par  (site web personnel) . Évalué à 2.

                C'est vrai que si l'on regarde de plus près cela n'a d'intérêt que si tu veux du scripts portable sur des vieux unix du siècle dernier encore en activité.
                Ce qui je le conçois maintenant n'a quasiment plus d’intérêt

              • [^] # Re: AH ah ah ...

                Posté par  . Évalué à 5.

                Yen a pas. Ça permet juste de montrer que:
                1) gérer des fichiers/répertoires, c’est toujours beaucoup plus compliqué qu’ils n’y parait
                2) le Shell est (ironiquement) horrible pour faire ça. Entre autres, on ne sait pas si ne pas créer les répertoires intermédiaires est un bug ou une feature, parce que l’api de mkdir fouette.

                En l’occurence, son script vol en morceau si ya un espace (ou potentiellement autre charactere chelou) dans $REP. Bon courage pour comprendre ce qu’il se passe aussi si ya une typo dans le nom de la variable.
                La leçon de l’installeur de steam qui faisait un rm -rf /$variable a pas a été retenue visiblement - utiliser des variables à la rache dans les manipulations de fichiers, c’est super dangereux.

                Linuxfr, le portail francais du logiciel libre et du neo nazisme.

                • [^] # Re: AH ah ah ...

                  Posté par  (site web personnel) . Évalué à 3.

                  Ceci dit :

                  Un script bash n'est a l'origine que la suite des commandes que l'on aurait tapé à la main
                  donc pas d'analyse juste une suite d'instructions à reproduire sans utilisateur

                  Ce n'est pas la même démarche pour un script python ou java ou grosso modo j'ai des données en entrées
                  sur lesquelles je vais appliquer un certain traitement puis générer éventuellement des données en sorties

                  • [^] # Re: AH ah ah ...

                    Posté par  . Évalué à 2.

                    Je dis peut-être une connerie, mais si tu tapes [ -d "$REP" ] || mkdir "$REP"

                    … Les espaces sont gérés non ?

                    • [^] # Re: AH ah ah ...

                      Posté par  . Évalué à 2.

                      Tout à fait, j'hallucine encore de voir des scripts ou exemples sans "" autour des variables désignant des fichiers ou des répertoires; et par extension toutes variables, sauf lorsque l'on souhaite en séparer les champs.
                      Bien sur on peut aussi jouer sur l'IFS, mais ça devient plus technique ;)

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

                      • [^] # Re: AH ah ah ...

                        Posté par  . Évalué à 3.

                        Tout à fait, j'hallucine encore de voir des scripts ou exemples sans "" autour des variables désignant des fichiers ou des répertoires; et par extension toutes variables

                        Pas tout à fait d’accord. Je n’en mets pas quand $VAR contient un entier.

                        Je dirais que dans un script bien écrit c’est la présence de guillemets qui te permet de déterminer qu’il s’agit d’une variable de type chaîne, pas d’un entier ou un tableau.

                    • [^] # Re: AH ah ah ...

                      Posté par  . Évalué à 1.

                      Sans les guillements, il y a quand même une certaine gestion des espaces:

                      $ REP="foo bar"
$ [ -d $REP ] && mkdir $REP ; echo $?
bash: [: foo: binary operator expected
2

                      ok, je sors …

                      • [^] # Re: AH ah ah ...

                        Posté par  . Évalué à 2. Dernière modification le 28 septembre 2017 à 10:52.

                        Mais si tu utilise explicitement bash, alors il n'y a pas de problème avec la version [[ ]], qui n'est pas une commande et sait distinguer les variables:

                        [[ -d $REP ]] || mkdir "$REP"

                        (mais pour mkdir, là il faut protéger bien entendu)

        • [^] # Re: AH ah ah ...

          Posté par  . Évalué à 3.

          Java est toujours "fortement typé" non

          Python est aussi fortement typé.

          Après, je pense que l'auteur trollait avec sa phrase. On ne va pas commencer à remplacer tous les scripts bash par du Java. Par contre, les scripts lié au build ou pour avoir un langage de script dans une application, ça peut avoir du sens d'uitliser ça plutôt que tu bash ou du Python.

          « 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: AH ah ah ...

            Posté par  (site web personnel) . Évalué à 1.

            Il peut l'être mais c'est pas obligatoire :)

            D'ailleurs le terme exact c'est typage dynamique ou statique => Typage Fort

            • [^] # Re: AH ah ah ...

              Posté par  . Évalué à 8.

              Typage fort/faible, ça n'a rien à voir avec dynamique/statique et d'ailleurs, c'est exactement ce qui est dit dans le lien que tu donne. Python et Java sont fortement typés mais Python est typé dynamiquement et Java statiquement.

              « 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: AH ah ah ...

                Posté par  (site web personnel) . Évalué à 2.

                Alors c'est le coté dynamique qui me plaît

                • [^] # Re: AH ah ah ...

                  Posté par  . Évalué à 3.

                  est-ce que c'est le côté dynamique ou le fait de ne pas avoir besoin d'expliciter les types ? (cf caml, scala, typescript…)

                  • [^] # Re: AH ah ah ...

                    Posté par  (site web personnel) . Évalué à 2.

                    Certainement …

                    • [^] # Re: AH ah ah ...

                      Posté par  (site web personnel) . Évalué à 2.

                      Alors désolé de t'en rajouter une couche, mais aux deux dimensions "fort - faible" et "statique - dynamique" tu peux en ajouter une troisième : la qualité de l'inférence.

                      Par exemple Scala est fortement et statiquement typé, mais infère beaucoup de choses, là ou Java infère que dalle.

                      • [^] # Re: AH ah ah ...

                        Posté par  . Évalué à 3.

                        Par exemple Scala est fortement et statiquement typé, mais infère beaucoup de choses, là ou Java infère que dalle.

                        Si, java faisait déjà un peu d'inférence en java 7, avec l'opérateur "diamant" qui permet d'écrire ça

                        List<String> lst=new ArrayList<>();

                        à la place de ça

                        List<String> lst=new ArrayList<String>();

                        Ensuite, les lambda de java 8 reposent beaucoup sur l'inférence pour déduire quelle interface l'expression lambda implémente et quels sont les types des paramètres éventuels de l'expression.
                        Ça permet par exemple, ayant une variable Map<String,Integer> map, de faire

                        map.forEach((k,v) -> System.out.println("double of "+k+": "+v*2));

                        où java 8 déduit tout seul que k est de type String et v de type Integer, à la place de

                        map.forEach(new BiConsumer<String, Integer>() {
    public void accept(String k, Integer v) {
        System.out.println("double of "+k+": "+v*2);
    }
});

                        Et pour les lambda qui implémentent une méthode qui retourne une valeur (comme java.util.function.Function) il déduit tout seul le type de retour en fonction du résultat de l'expression, ou en fonction du return si on met un bloc de code dans la lambda.

                        Et pour aller plus loin, li y a le JEP 286, qui malheureusement n'a pas été inclus dans java 9 et dont on espère que ce sera pour java 10.

                        • [^] # Re: AH ah ah ...

                          Posté par  (site web personnel) . Évalué à 1.

                          Au temps pour moi, je me suis arrêté à Java 6 mais c'est vrai dans les versions suivantes ils ont bien bûché à copier Scala :-P

                        • [^] # Re: AH ah ah ...

                          Posté par  . Évalué à 1. Dernière modification le 29 septembre 2017 à 15:23.

                          Hou la faut pas confondre.

                          En java une Collection<String> est la même chose que Collection tout court; c'est du sucre syntaxique pour éviter d'écrire des connerie (le compilo les repères), mais ne change en aucun cas le type sous-jacent; ce qui fait qu'on ne peut pas écrire 

                          void plop(Collection<String> bidule)
{
 //...
}

void plop(Collection<Integer> bidule)
{
 //...
}

                          les deux fonction plop ayant la même signature; pour quelqu'un venant du c++ et ayant l'habitude d'utiliser 2/3 template, cette limitation est très chiante.

                          Le coup du diamond (<>) est juste une facilité d'écriture; qui évite d'écrire de la redondance.

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

                          • [^] # Re: AH ah ah ...

                            Posté par  . Évalué à 3.

                            Les génériques ne sont pas que du sucre syntaxique (contrairement au "foreach" introduit dans java 5 et au "try with resource" introduit dans java 7), il sont perdu à l'exécution, mais le compilateur les vérifie vraiment et n'acceptera pas que tu donne une variable déclarée comme Collection à une fonction qui attends une Collection.
                            Avec quoi crois-tu que je les confonde?

                            Quand à ton exemple, ça s'appelle de la surcharge, et c'est orthogonal avec l'inférence ce sur quoi je répondais).

                • [^] # Re: AH ah ah ...

                  Posté par  (site web personnel) . Évalué à 2.

                  Donc un langage fortement et statiquement typé, mais avec de l'inférence de type correcte pourrait te plaire ?

                  J'utilise tous les jours Haskell pour "scripter": le code est concis grâce à l'inférence, mais j'ai beaucoup plus d'outils à ma.disposition pour m'exprimer et économiser du temps tout en rendant le code un peu plus robuste. (Les scripts qui plantent au bout de 45 minutes à cause d'une variable mal nommée cela m'énerve ;)

  • # .

    Posté par  (site web personnel) . Évalué à 6.

    Les fichiers *.properties pourront enfin être écrits en UTF-8. Ces fichiers, souvent utilisés pour l'internationalisation, étaient limités à ISO-8859-1…

    En réalité avec des outils un tant soit peu modernes, on peut les écrire en UTF-8 depuis longtemps. Mais c'était une entorse à la norme JEE sans garantie de fonctionnement dans tous les conteneurs, certes.

    • [^] # Re: .

      Posté par  (site web personnel) . Évalué à 2.

      avec des outils un tant soit peu modernes

      tu mets eclipse et notepad++ ainsi que vi dans le lot ? Il y a emacs aussi ? (eh oh c'est encore dredi !)

      • [^] # Re: .

        Posté par  (site web personnel) . Évalué à 2.

        Pendant des années j'ai écrit des .properties en UTF-8 avec Eclipse, donc oui je le mets dans le lot des outils qui le permettent. Je n'utilise pas vraiment N++ ni vi ni emacs mais je doute qu'ils refusent d'éditer des .properties en unicode.

        • [^] # Re: .

          Posté par  . Évalué à 2.

          Soit je n'ai pas compris la blague de BAud, soit il n'utilise que les éditeurs pour hipsters à la Atom IDE (fraîchement sorti ce mois-ci (pas Atom mais Atom augmenté de modules "Language Server Protocol" pour en faire un IDE)).
          Je code sous ViM en UTF-8 depuis des années, je n'imagine pas qu'Emacs OS n'en soit pas capable. Même notepad.exe le fait.

  • # Compact Strings

    Posté par  (site web personnel) . Évalué à 7.

    Les chaînes de caractères prendront moins de place en mémoire si elles contiennent des caractères latin1.

    Ah enfin ! Ça va pouvoir faire chuter le prix de la RAM !
    -->[]

  • # Écrivons en français

    Posté par  . Évalué à -4.

    'Java 9 est dehors' est la traduction littérale de l'anglais 'java 9 is out'.
    Équivalent en français: 'java 9 est sorti'.

Suivre le flux des commentaires

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