IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Java Discussion :

Oracle présente de nouvelles fonctionnalités de Java 9


Sujet :

Java

  1. #21
    Membre émérite

    Profil pro
    Inscrit en
    décembre 2003
    Messages
    3 995
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : décembre 2003
    Messages : 3 995
    Points : 2 288
    Points
    2 288
    Par défaut
    Citation Envoyé par tchize_ Voir le message
    Il est clair qui si on vois java remplaçant javascript, il va falloir passer par autoriser la programmation fonctionnelle. Ceci dit groovy, c'est du java et ça le permet, donc c'est loin d'être impossible :p

    puis les javascriptien sont de plus en plus habitués à la poo avec jquery & co
    La programmation fonctionnelle, c'est LA grosse nouveauté de Java 8, et ça a l'air de cartonner.

    http://www.developpez.com/actu/75831...dministration/

  2. #22
    Responsable .NET

    Avatar de Hinault Romaric
    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2007
    Messages
    4 570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 4 570
    Points : 252 325
    Points
    252 325
    Billets dans le blog
    117
    Par défaut
    Le projet Jigsaw s’invite dans Java
    Les développeurs peuvent tester la modularité dans la dernière « Early Access » du JDK 9

    Le projet Jigsaw fait, enfin, ses premiers pas dans le JDK. Les développeurs peuvent tester cette nouveauté dans une récente version de la « Early Access » du JDK 9.

    L’objectif du projet Jigsaw est de concevoir et mettre en œuvre un système de modules standards pour Java SE, et d’appliquer ce système pour la plateforme elle-même et pour le JDK. Le projet Jigsaw permettra de découper la bibliothèque d’exécution de base de Java en différents modules. Cela devrait permettre à une machine virtuelle Java (JVM) de fonctionner sans le support de certains packages de base.

    À la suite d'un travail préliminaire qui avait abouti à une proposition en 2008, le système de modules du projet Jigsaw allait être l’une des principales innovations de Java 7. Le projet avait été ensuite reporté à Java 8, puis finalement, Oracle avait annoncé sa sortie avec Java 9, prévue pour début 2016.

    Oracle fait face à plusieurs défis dans le développement de ce projet qui permettra de redéfinir l’architecture de la plateforme. La principale difficulté à laquelle ont fait face les ingénieurs d’Oracle était liée aux dépendances qui existent entre les packages.

    Cette préversion est basée sur Jigsaw m2, qui implémente la JEP (JDK Enhancement Proposals) 200 (qui définit la structure modulaire du JDK), JEP 201 (qui réorganise le code source du JDK sous forme de module) et JEP 220 (qui restructure le runtime du JDK et JRE pour soutenir les modules).

    Les développeurs en charge du projet ont débuté avec la JSR (Java Specification Requests) 376, qui permettra de rendre le système de module effectif dans la plateforme Java.

    Il faut noter que le passage à un système de module aura également un impact important sur les outils de développement et les Framework. « Nous sommes conscients que ces changements vont briser certaines applications, en particulier les IDE et les outils de développement qui s’appuient sur la structure interne du JDK. », écrit Mark Reinhold, architecte en chef du groupe de la plateforme Java chez Oracle, dans un billet de blog. « Nous pensons cependant que les améliorations des performances, de la sécurité et de la maintenabilité donnent un sens à ces changements. »

    Les ingénieurs d’Oracle ont d’ores et déjà contacté les développeurs des principaux environnements de développement pour s’assurer qu’ils ont pris connaissance de ces changements et sont prêts, si nécessaire, à travailler avec ceux-ci.

    Mark Reinhold avait déjà fait savoir qu’avec Jigsaw, le format JAR n’avait plus sa place dans le système d’exécution de Java. « Le format JAR a fait son temps, c'est le moment de passer à autre chose », avait affirmé celui-ci. La plateforme Java continuera, cependant, à prendre en charge et à exécuter les applications empaquetées dans les fichiers Jar.

    En plus de l’intégration du projet Jigsaw, des modifications ont été également apportées à certaines JEP. Il s’agit notamment de la JEP 158 (Unified JVM Logging), qui introduit un système d’enregistrement commun pour toutes les composantes de la machine virtuelle Java. Cette JEP a été fortement influencée par ce qui existe dans la machine virtuelle JRockit d’Oracle.

    La JEP 165 (Compiler Control) a aussi eu droit à des améliorations, tout comme la JEP 214 (Remove GC Combinations Deprecated in JDK 8) et la JEP 213 (Milling Project Coin).

    La « Early Access » de JDK 9 est disponible en téléchargement sur le site du projet.

    Télécharger la « Early Access » du JDK 9

    Source : Billet de blog de Mark Reinhold
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

  3. #23
    Membre confirmé Avatar de bruneltouopi
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2010
    Messages
    308
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Ile Maurice

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2010
    Messages : 308
    Points : 466
    Points
    466
    Par défaut
    J'espère que ce changement au vu de son impact,Oracle va prévoir des processus de migrations surtout pour des applications en production.
    Sinon je vois déjà pleins d'entreprises qui resteront dans le JDK 8.
    Ce qui ne me tue pas me rend plus fort.

  4. #24
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 25 481
    Points : 48 820
    Points
    48 820
    Par défaut
    Jusqu'à présent, la compatibilité a toujours été assurée en java, je ne vois pas ce qui te fait penser que ce ne serait plus le cas.

  5. #25
    Responsable .NET

    Avatar de Hinault Romaric
    Homme Profil pro
    Consultant
    Inscrit en
    janvier 2007
    Messages
    4 570
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2007
    Messages : 4 570
    Points : 252 325
    Points
    252 325
    Billets dans le blog
    117
    Par défaut
    Java 9 sortira en version stable le 22 septembre 2016
    le gel des fonctionnalités est prévu pour le 10 décembre 2015

    Mark Reinhold, architecte en chef du groupe de la plateforme Java chez Oracle, vient de présenter la feuille de route pour le développement de Java 9, qui devrait aboutir à la publication de la version stable dans 15 mois.

    Le calendrier prévoit ce qui suit :


    • 10/12/2015 : intégration de toutes les fonctionnalités dans la branche principale ;
    • 04/02/2016 : finalisation des tests sur toutes les plateformes supportées ;
    • 25/02/2016 : contrôle des changements entrants ;
    • 21/04/2016 : finalisation avec le traitement du carnet des bogues :
    • 16/06/2016 : deuxième série de contrôle des changements entrants ;
    • 27/06/2016 : publication de la Release Candidate finale ;
    • 22/09/2016 : disponibilité générale de Java 9, pour une utilisation en environnement de production.


    Le responsable du développement de Java précise que ces dates ont été définies de façon à laisser suffisamment de temps pour l’examen général, les tests des caractéristiques importantes, en particulier l’introduction d’un système de module.

    Toutefois, le calendrier doit être pris avec réserve. Car avec les fonctionnalités importantes dont dispose cette version, il n’est pas exclus qu’un blocage puisse entrainer un report. Il faut rappeler que Java 8 avait été reporté afin de colmater les failles de sécurité dans la plateforme.

    Actuellement, Java 9 peut être testé à travers la dernière préversion (Early Access) du JDK 9 qui est disponible sur le site du projet. Au menu des caractéristiques qui avaient été présentées par Oracle, on peut noter :


    • l’intégration de « HTTP2 Client » pour le support du HTTP 2.0 et des web sockets ;
    • l’ajout de « Process API Updates » qui permet d’améliorer le contrôle, la gestion et l’interaction avec les processus non Java ;
    • l’introduction d’un système d’enregistrement commun pour tous les composants de la JVM ;
    • Plus de contrôle au niveau de la compilation ;
    • Des améliorations pour le projet Coin, qui avait été introduit avec Java 7 ;
    • Le support des modules et bien plus.


    La fonctionnalité la plus attendue est, sans aucun doute, la prise en charge de la modularité (projet Jigsaw). Cette fonctionnalité a entrainé de gros changements au JDK. Elle permettra de découper la bibliothèque d’exécution de base de Java en différents modules. Ainsi, une machine virtuelle Java (JVM) pourra fonctionner sans le support de certains packages de base.

    Les défis a relevé avec ce projet ont été nombreux pour les ingénieurs d’Oracle. Son implémentation avait été initialement prévue avec Java 8. Le projet a été repoussé à Java 9 et il a été redéfini à maintes reprises.

    Avec Java 9, Oracle se donne pour mission de publier une nouvelle version de la plateforme tous les deux ans.

    Télécharger la Early Access du JDK 9

    Source : OpenJDK
    Vous souhaitez participer aux rubriques .NET ? Contactez-moi

    Si déboguer est l’art de corriger les bugs, alors programmer est l’art d’en faire
    Mon blog, Mes articles, Me suivre sur Twitter
    En posant correctement votre problème, on trouve la moitié de la solution

  6. #26
    MikeRowSoft
    Invité(e)
    Par défaut
    Je me demande bien comment fonctionne cette machine virtuelle. Je crois qu'il y a des fichiers exécutables pour l'intégration avec les systèmes d'exploitations, mais pas de scripts pour une interaction direct comme pour JavaScript ou Visual Basic Script ou Script Shell ou autres. Je comprend mieux pourquoi Java... Ils ont une priorité défini, même si ils peuvent la changé à leurs guises dans certains cas.

  7. #27
    Membre averti
    Profil pro
    Inscrit en
    juin 2006
    Messages
    179
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : juin 2006
    Messages : 179
    Points : 388
    Points
    388
    Par défaut
    Citation Envoyé par MikeRowSoft Voir le message
    Je me demande bien comment fonctionne cette machine virtuelle.
    La machine virtuelle : http://jmdoudoux.developpez.com/cours/developpons/java/

    Citation Envoyé par MikeRowSoft Voir le message
    Je crois qu'il y a des fichiers exécutables pour l'intégration avec les systèmes d'exploitations, mais pas de scripts pour une interaction direct comme pour JavaScript ou Visual Basic Script ou Script Shell ou autres.
    On peut créer des exécutables par plateforme (.exe) mais aussi exécuter des scripts (javascript, groovy, python etc.) pas de soucis à ce niveau là. La JVM ne fait pas tourner qu'un langage ! http://en.wikipedia.org/wiki/List_of_JVM_languages

    Citation Envoyé par MikeRowSoft Voir le message
    Ils ont une priorité défini, même si ils peuvent la changé à leurs guises dans certains cas.
    Le Java Community Process a son mot à dire : http://fr.wikipedia.org/wiki/Java_Community_Process

    En espérant t'avoir éclairé

  8. #28
    MikeRowSoft
    Invité(e)
    Par défaut
    Citation Envoyé par Washmid Voir le message

    En espérant t'avoir éclairé
    Merci, mais je connais déjà cela. Ça ne m'a pas éclairer au sujet l'analyse syntaxique et grammaticale en encore moins au sujet du contenu des dossiers Java. Je crois pas que cela fasse parti de beaucoup de cours universitaires ou de cycles d'ingénieurs, encore moins de B.T.S. ou formations tiers. Cela ce rapproche plus de la certification.
    Dernière modification par MikeRowSoft ; 08/05/2015 à 00h22.

  9. #29
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 688
    Points
    7 688
    Par défaut
    Toujours pas d'amélioration sur les Properties après tant d'années. C'est peut être qu'on s'est habitué à l'idée que c'était le travail d'un IDE de générer les 50-200 lignes de plomberie nécessaires aux objets utilisés comme conteneur de données.
    Pas non plus de named arguments, de nouveau on va demander à l'IDE de générer un parameter object et une sorte de builder bien lesté. Deux classes pour faire ce qu'une simple syntaxe "name = Jean, age = 10" aurait permis, la sécurité en moins puisqu'on peut toujours oublier de renseigner une propriété dans un builder.

    C'est fou mais j'ai l'impression que la puissance des outils de développement a poussé SUN et Oracle a se détourner complètement des lourdeurs à l'écriture de code java.

  10. #30
    Modérateur
    Avatar de Gugelhupf
    Homme Profil pro
    Analyste Programmeur
    Inscrit en
    décembre 2011
    Messages
    1 309
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Analyste Programmeur

    Informations forums :
    Inscription : décembre 2011
    Messages : 1 309
    Points : 3 639
    Points
    3 639
    Billets dans le blog
    12
    Par défaut
    Comment améliorer les fichiers de Properties ? Cela a toujours été un fichier plat contenant des paires clé/valeur de chaine depuis le JDK 1.0. Pour des notions plus avancés il y a notamment les fichiers XSD et génération de classes JAXB, qui sont certes lourd à mettre en place, mais je n'ai pas compris l'alternative.
    N'hésitez pas à consulter la FAQ Java, lire les cours et tutoriels Java, et à poser vos questions sur les forums d'entraide Java

    Ma page Developpez | Mon profil Linkedin | Vous souhaitez me contacter ? Contacter Gokan EKINCI

  11. #31
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par _skip Voir le message
    Toujours pas d'amélioration sur les Properties après tant d'années. C'est peut être qu'on s'est habitué à l'idée que c'était le travail d'un IDE de générer les 50-200 lignes de plomberie nécessaires aux objets utilisés comme conteneur de données.
    Apparemment il y aura juste enfin le support des fichiers properties en utf8 : http://openjdk.java.net/jeps/226
    Quelles genres d'améliorations tu voudrais ?


    Citation Envoyé par _skip Voir le message
    Pas non plus de named arguments, de nouveau on va demander à l'IDE de générer un parameter object et une sorte de builder bien lesté. Deux classes pour faire ce qu'une simple syntaxe "name = Jean, age = 10" aurait permis, la sécurité en moins puisqu'on peut toujours oublier de renseigner une propriété dans un builder.
    Les named arguments c'est bien mais cela pose plusieurs problèmes car c'est peu évolutif :
    • Il faut stocker le nom des paramètres dans les fichiers classes, ce qui n'est pas le cas actuellement sauf à utiliser une option de compilation spécifique.
    • Cela change le status des noms de paramètres, en les rendant "critique" (le simple fait de les changer peut aboutir à une incompatibilité), alors que ce n'est pas plus important qu'un commentaire actuellement.
      Et surtout cela s'appliquerait à tous les paramètres de toutes les méthodes existantes...
    • On s'attend logiquement à ce que cela soit associé à des paramètres par défaut... et cela pose plein de problèmes et d'ambiguités avec la surcharge et la redéfinition !
    • Pire que cela çà rend l'évolution de la méthode complexe et peu intuitive, puisque la moindre modification va générer des incompatibilités binaires, car contrairement à ce qu'on pourrait penser l'ajout d'un paramètre optionnel correspond à un changement incompatible !!



    Exemple: Imagine qu'on ait une méthode comme ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    public class TypeA {
        public void method (String name, int age=0) {
            System.out.println(name + " " + age);
        }
    }
    Les paramètres nommés/optionnels fonctionnent via du sucre syntaxe à l'exécution, qui s'occupe de remplacer les valeurs et d'effectuer le bon appel de méthode :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    TypeA a = ...
     
    a.method(name:"Fred");
    a.method(age: 25, name:"Eric");
     
    // est équivalent à :
     
    a.method("Fred", 0);
    a.method("Eric", 25);

    Maintenant si on veut faire évoluer notre méthode en lui rajoutant un paramètre ("firstName" par exemple), en toute logique on essayerait ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    public class TypeA {
        public void method (String name, int age=0, String firstName=null) {
            System.out.println(name + " " + Objects.toString(firstName,"") + " " + age);
        }
    }
    Et çà marche ! Youpi on est content et on déploie notre code...
    Sauf que cela marche bien dans notre éditeur car il va s'occuper de tout recompiler comme il faut... mais on vient de générer une incompatibilité binaire avec tous les codes qui utilisait notre méthode.


    En effet si on n'a pas recompilé le code, il tente toujours d'appeler une méthode method(String,int) qui n'existe plus, ce qui va générer un beau MethodNotFoundException...


    Et pour éviter cela il faut revenir à la surcharge afin que la méthode originelle soit toujours présente :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    public class TypeA {
        public void method (String name, int age) {
            method(name, age, null);
        }
     
        public void method (String name, int age=-1, String firstName=null) {
            System.out.println(name + " " + Objects.toString(firstName,"") + " " + age);
        }
    }


    Second effet kiss-cool : je veux renommer mon paramètre "name" (désormais le terme "lastName" serait plus approprié)... mais cela provoquerait une incompatibilité des sources obligeant la modification de l'appel de la méthode en cas de recompilation !

    De même si j'ai une méthode anodine du genre setEnabled(boolean b), et je souhaite renommer le paramètre "b" en "enabled" qui me semble plus approprié... mais cela provoquerait des incompatibilité avec deux qui l'aurait utilisé comme ceci setEnabled(b:true) !

    Et encore je n'ai même pas parlé d'éventuelle redéfinition dans une classe fille qui viendrait encore plus embrouillé le tout, ou encore de la valeur par défaut qui dépend aussi de la compilation !!!




    Bref les paramètres nommées/optionnels c'est bien dans un langage de script comme PHP (car tout est réinterprété à chaque exécution) ou alors limité au sein d'une même application (mais comment limité cela ?).
    Mais dans un langage plus complexe et compilé comme Java cela peut apporter son lot de problèmes...



    Le "Builder" reste une bien meilleure solution pour le moment... même si c'est plus lourd.
    A la rigueur selon la syntaxe finale cela pourrait être remplacé par des type-values...

    a++

  12. #32
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 688
    Points
    7 688
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    Apparemment il y aura juste enfin le support des fichiers properties en utf8 : http://openjdk.java.net/jeps/226
    Quelles genres d'améliorations tu voudrais ?
    Je vois que j'ai pas été clair, je parlais de propriétés au sens getter/setter. Pas pensé une seule seconde à la confusion que cela pouvait engendrer avec le format .properties

    [*] Il faut stocker le nom des paramètres dans les fichiers classes, ce qui n'est pas le cas actuellement sauf à utiliser une option de compilation spécifique.
    Juste, c'est vrai qu'actuellement le nom se perd à la compilation ce qui peut être un problème si on a pas la source à dispositon mais juste les .class ou un jar. Mais plein de langages pour la JVM ont prouvé que c'était largement possible.

    Cela change le status des noms de paramètres, en les rendant "critique" (le simple fait de les changer peut aboutir à une incompatibilité), alors que ce n'est pas plus important qu'un commentaire actuellement.
    Et surtout cela s'appliquerait à tous les paramètres de toutes les méthodes existantes...
    Ca n'a rien d'anodin à mon sens de modifier les paramètres d'une méthode, je trouve pas que changer le nom des arguments soit très normal non plus sur une API destinée au grand monde (encore plus si le changement est aussi sémantique) enfin tout à fait au même titre qu'une modification de signature. Question de point de vue, surtout que si tu utilises nommément un argument dans un appel, tu acceptes de dépendre du nom de l'argument en le considérant comme un élément à part entière de la signature, ce que tu n'es absolument pas obligé de faire puisque la syntaxe positionnelle continuerait de fonctionner.

    [*] On s'attend logiquement à ce que cela soit associé à des paramètres par défaut... et cela pose plein de problèmes et d'ambiguités avec la surcharge et la redéfinition !
    Non perso je vois plein de cas d'utilisation valide où ça n'a rien à voir avec des défauts. Même si les défauts sont une évolution valide.

    Pire que cela çà rend l'évolution de la méthode complexe et peu intuitive, puisque la moindre modification va générer des incompatibilités binaires, car contrairement à ce qu'on pourrait penser l'ajout d'un paramètre optionnel correspond à un changement incompatible !!
    Dans le cas où la magie s'opère à la compilation, je vois pas trop ce que ça pourrait venir ennuyer. Pour le reste c'est simple, tu mets à jour ton code, tu dois renommer l'argument auquel tu fais référence, je suis persuadé que si c'était là le problème, les IDE seraient assez intelligents pour te faire ça. Le seul ennui que je vois c'est si tu essaies soudainement de compiler avec une autre version d'un jar externe où un nom a été changé. Là oui ton code compile plus car la liste d'argument est différente, question : C'est aussi grave que ça sachant que c'est détecté à la compilation? Et même est-ce que ça peut pas attirer ton attention sur un possible changement sémantique?


    Bref les paramètres nommées/optionnels c'est bien dans un langage de script comme PHP (car tout est réinterprété à chaque exécution) ou alors limité au sein d'une même application (mais comment limité cela ?).
    Mais dans un langage plus complexe et compilé comme Java cela peut apporter son lot de problèmes...
    Ce ne sont pas des problèmes, mais de possibles inconvénients. L'ancien code continuerait d'être fonctionnel puisqu'on parle d'introduire une syntaxe alternative qui n'existe pas donc ces problèmes se poseraient principalement sur le nouveau code (java 9+).
    Perso je trouve que les parameters objects + builders particulièrement lourds, et bien moins sécurisants encore.

  13. #33
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par _skip Voir le message
    Je vois que j'ai pas été clair, je parlais de propriétés au sens getter/setter. Pas pensé une seule seconde à la confusion que cela pouvait engendrer avec le format .properties
    Ah oui en effet j'ai tout compris de travers !
    Tout à fait d'accord là dessus



    Citation Envoyé par _skip Voir le message
    Juste, c'est vrai qu'actuellement le nom se perd à la compilation ce qui peut être un problème si on a pas la source à dispositon mais juste les .class ou un jar. Mais plein de langages pour la JVM ont prouvé que c'était largement possible.
    Il est déjà possible de sauvegarder le nom dans le fichier .class (option -parameters de javac).
    C'est surtout de l'intégrer par défaut qui peut être problématique.

    Citation Envoyé par _skip Voir le message
    Ca n'a rien d'anodin à mon sens de modifier les paramètres d'une méthode, je trouve pas que changer le nom des arguments soit très normal non plus sur une API destinée au grand monde (encore plus si le changement est aussi sémantique) enfin tout à fait au même titre qu'une modification de signature. Question de point de vue, surtout que si tu utilises nommément un argument dans un appel, tu acceptes de dépendre du nom de l'argument en le considérant comme un élément à part entière de la signature, ce que tu n'es absolument pas obligé de faire puisque la syntaxe positionnelle continuerait de fonctionner.
    Pourtant les APIs regorgent de noms de paramètres à une lettre (y compris dans l'API standard)... surtout dans les premières version mal documenté.
    Ce serait dommage de se trimballer cela à vie sans pouvoir corriger cela (hormis via de possibles incompatibilités).
    Sur une méthode on a au moins la solution de dupliquer/déprécier...

    Le problème justement c'est que tu n'as aucun moyen de corriger cela sans générer des incompatibilités !


    Cela change carrément la signature de méthode, en y ajoutant une contrainte supplémentaire (le nom du paramètre).
    Quid des redéfinitions ? A-t-on le droit de renommer les paramètres dans une classe fille ?


    Citation Envoyé par _skip Voir le message
    Non perso je vois plein de cas d'utilisation valide où ça n'a rien à voir avec des défauts. Même si les défauts sont une évolution valide.
    Le problème des paramètres par défaut c'est que cela s'applique mal avec la surcharge...
    Cela aurait été bien moins problématique sans surcharge... beaucoup de chose aurait été moins problématique sans surcharge !


    Citation Envoyé par _skip Voir le message
    Dans le cas où la magie s'opère à la compilation, je vois pas trop ce que ça pourrait venir ennuyer. Pour le reste c'est simple, tu mets à jour ton code, tu dois renommer l'argument auquel tu fais référence, je suis persuadé que si c'était là le problème, les IDE seraient assez intelligents pour te faire ça. Le seul ennui que je vois c'est si tu essaies soudainement de compiler avec une autre version d'un jar externe où un nom a été changé. Là oui ton code compile plus car la liste d'argument est différente, question : C'est aussi grave que ça sachant que c'est détecté à la compilation? Et même est-ce que ça peut pas attirer ton attention sur un possible changement sémantique?
    C'est grave dans le sens où cela peut empêcher les développeurs de librairies de l'améliorer.
    Une ou deux erreurs c'est pas bien grave... mais des modifications massives peuvent lourdement impacter un code source.
    Si demain la nouvelle version d'une librairie (ou de Java) te génère 5000 erreurs, tu risques de l'éviter et de retarder son utilisation... tout çà parce qu'ils ont modifié le nom de quelques paramètres...

    Une incompatibilité (de source ou binaire) est toujours problématique.
    Du coup cela pourrait pousser les devs à retarder cela et à laisser le code tel quel...

    D'un point de vue developpeurs c'est certe une fonctionnalité sympa.
    Mais du point de vue d'un concepteur de librairie cela peut avoir beaucoup de coté négatif aussi.


    Citation Envoyé par _skip Voir le message
    Ce ne sont pas des problèmes, mais de possibles inconvénients.
    Non ce sont des problèmes réels, qui existe déjà sous C# par exemple.

    Citation Envoyé par _skip Voir le message
    L'ancien code continuerait d'être fonctionnel puisqu'on parle d'introduire une syntaxe alternative qui n'existe pas donc ces problèmes se poseraient principalement sur le nouveau code (java 9+).
    Oui mais le problème c'est que cela impacterait tous les codes dès la sortie de java 9, même s'il n'est pas forcément destiné à utiliser les named parameters...


    Une alternative pourrait consister à limiter cela à certaines méthodes non-virtuelles marquées par un mot-clef précis.
    Cela limiterait pas mal de problème, même si je ne vois pas trop de solution pour les paramètres par défaut (à moins d'interdire la surcharge sur ces méthodes).

    Citation Envoyé par _skip Voir le message
    Perso je trouve que les parameters objects + builders particulièrement lourds, et bien moins sécurisants encore.
    Oui c'est lourd (je n'ai jamais dit le contraire).
    Mais c'est plus évolutif...


    a++

  14. #34
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    novembre 2006
    Messages
    7 184
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : novembre 2006
    Messages : 7 184
    Points : 9 309
    Points
    9 309
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    Il serait donc possible de voir des navigateurs inclurent un Java "minimum", le tout couplé à un module "browser" permettant une communication simple avec le browser, et des modules optionnelles représentant les fonctionnalités "html5"...
    Et on pourrait se retrouver à codé des applications Java qui tourneraient directement dans le navigateur.
    Personnellement, je trouve l'idée excellente... on aurait presque l'équivalent de l'applet que tout le monde a tué alors que le potentiel était énorme
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  15. #35
    Expert éminent
    Avatar de _skip
    Homme Profil pro
    Développeur d'applications
    Inscrit en
    novembre 2005
    Messages
    2 898
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur d'applications
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : novembre 2005
    Messages : 2 898
    Points : 7 688
    Points
    7 688
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    Non ce sont des problèmes réels, qui existe déjà sous C# par exemple.
    Non je suis pas d'accord avec toi là, ce sont plutôt des inconvénients, c'est une syntaxe facultative qui ne pose que des problèmes assez mineurs à la compilation et seulement dans des cas un peu fumeux. Dans les langages où cela existe, c'est utilisé pour améliorer la lisibilité de certains appels complexes, rarement de façon systématique, ce qui dilue encore plus le problème.

  16. #36
    Membre confirmé Avatar de bruneltouopi
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    janvier 2010
    Messages
    308
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Ile Maurice

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : janvier 2010
    Messages : 308
    Points : 466
    Points
    466
    Par défaut
    C est une très bonne nouvelle. La sortie de chaque version après 2 ans
    Ce qui ne me tue pas me rend plus fort.

  17. #37
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 25 481
    Points : 48 820
    Points
    48 820
    Par défaut
    Citation Envoyé par MikeRowSoft Voir le message
    Merci, mais je connais déjà cela. Ça ne m'a pas éclairer au sujet l'analyse syntaxique et grammaticale en encore moins au sujet du contenu des dossiers Java. Je crois pas que cela fasse parti de beaucoup de cours universitaires ou de cycles d'ingénieurs, encore moins de B.T.S. ou formations tiers. Cela ce rapproche plus de la certification.
    Ca peut prendre du temps de comprendre ce que tu cherche à savoir et te répondre, donc ce serait mieux que tu fasse un sujet à part avec ta question qui n'est pas trop liée à cette discution

  18. #38
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : avril 2002
    Messages : 13 938
    Points : 23 015
    Points
    23 015
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par _skip Voir le message
    Non je suis pas d'accord avec toi là, ce sont plutôt des inconvénients, c'est une syntaxe facultative qui ne pose que des problèmes assez mineurs à la compilation et seulement dans des cas un peu fumeux.
    Autant je suis d'accord avec toi concernant les avantages, autant je ne trouve pas que ce soient seulement des "inconvénients".

    Dans un même programme cela ne pose pas vraiment problème, mais dès que tu développes une librairie cela peut devenir critique.

    • Renommer un paramètre entraine une incompatibilité de type source (le code existant pourraient ne plus compiler), sans aucune alternative possible.
    • Modifier la valeur par défaut d'un paramètre entraine une incompatibilité de comportement (le même code produira un résultat différent selon la version avec laquelle il est modifié).
    • L'ajout d'un paramètre par défaut entraine une incompatibilité binaire (le code existant ne pourra pas s'exécuter sans être recompilé), et il faut opter pour une surcharge de la méthode afin de rester compatible... ce qui peut apporter des ambiguités de résolution de méthode.


    Le compatibility guide de chaque nouvelle version de Java recense des "problèmes" bien moins problématique que cela...


    Et cela sans même parler des ambiguïtés lié à un nommage différent des paramètres dans une classe fille (et il doit déjà y avoir des milliards de code où c'est le cas).



    Citation Envoyé par _skip Voir le message
    Dans les langages où cela existe, c'est utilisé pour améliorer la lisibilité de certains appels complexes, rarement de façon systématique, ce qui dilue encore plus le problème.
    Comme je l'ai dit c'est très bien dans une application, mais pas dans une librairie.
    Le problème c'est que rien ne le limite à certains appels complexes... donc cela impacterait toutes les méthodes existantes.
    C'est çà qui me pose problème.



    a++

  19. #39
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : avril 2007
    Messages : 25 481
    Points : 48 820
    Points
    48 820
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    Autant je suis d'accord avec toi concernant les avantages, autant je ne trouve pas que ce soient seulement des "inconvénients".

    Dans un même programme cela ne pose pas vraiment problème, mais dès que tu développes une librairie cela peut devenir critique.

    • Renommer un paramètre entraine une incompatibilité de type source (le code existant pourraient ne plus compiler), sans aucune alternative possible.
    • Modifier la valeur par défaut d'un paramètre entraine une incompatibilité de comportement (le même code produira un résultat différent selon la version avec laquelle il est modifié).
    • L'ajout d'un paramètre par défaut entraine une incompatibilité binaire (le code existant ne pourra pas s'exécuter sans être recompilé), et il faut opter pour une surcharge de la méthode afin de rester compatible... ce qui peut apporter des ambiguités de résolution de méthode.
    Si les paramètres par défaut sont du sucre syntaxique uniquement, ça ne devrais pas poser de problème de compatibilité au niveau binaire:

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
     
    public X maMethode(String val1, String val2 default "Hello", String val3 default "Prout"){....}
    pourrait être transformé par le compilateur en

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    public X maMethode(String val1, String val2, String val3);{....};
    public void maMethode(String val1, String val2) {return maMethode(val1,val2,"Prout");}
    public void maMethode(String val1) {return maMethode(val1,"Hello","Prout");}

    Celui qui appelat par le passé maMethode("blabla") peut toujours appeler maMethode("blabla"); sans recompilation. La méthode existe bien. C'est juste que le dev de la librairie a pas du se casser le cul à la créer.

    Ca pourrait être étendu aux interface d'ailleurs, en jouant avec les default methods.

    Bien sûr, si l'idée est de permettre d'appeler
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    machin.maMethode("blabla", val3:"Prout")
    , ca ne sera pas possible. Pour la simple raison qu'en java le nom du paramètre disparait à la compilation si tu n'inclus pas les options de debuggage.

    Donc des parametres default pourquoi pas, mais ce sera obligatoirement du droite à gauche: si je ne mentionne pas le deuxième paramètre dans l'appel, je ne mentionne pas non plus le troisième.

  20. #40
    Membre du Club
    Homme Profil pro
    passionné d'informatique
    Inscrit en
    mai 2013
    Messages
    32
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : passionné d'informatique

    Informations forums :
    Inscription : mai 2013
    Messages : 32
    Points : 47
    Points
    47
    Par défaut
    J'attends de voir si Java vas pouvoir un jour concurrencer des langage comme le C++
    Et de voir si minecraft pourra devenir un peu plus stable.

Discussions similaires

  1. Oracle lance une nouvelle tentative pour intégrer la modularité à Java
    Par Hinault Romaric dans le forum Général Java
    Réponses: 54
    Dernier message: 05/11/2013, 09h37
  2. Java : Oracle adopte une nouvelle nomenclature pour les mises à jour du JDK
    Par Cedric Chevalier dans le forum Général Java
    Réponses: 8
    Dernier message: 20/05/2013, 18h58
  3. Oracle dans une nouvelle bataille juridique sur l'utilisation du Java
    Par Hinault Romaric dans le forum Général Java
    Réponses: 16
    Dernier message: 17/12/2010, 16h01
  4. Oracle dans une nouvelle bataille juridique sur l'utilisation du Java
    Par Hinault Romaric dans le forum Actualités
    Réponses: 14
    Dernier message: 16/12/2010, 17h30

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo