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

Langage Java Discussion :

Oracle redonne un élan au Projet Lambda sur Java 7 et les closures : Interface evolution via "public defender"


Sujet :

Langage Java

  1. #1
    Expert éminent sénior


    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    7 856
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 7 856
    Points : 34 380
    Points
    34 380
    Par défaut Oracle redonne un élan au Projet Lambda sur Java 7 et les closures : Interface evolution via "public defender"
    Bonjour,

    Depuis quelques temps, on n'entendait plus trop parler des Closures et de leur ajout à Java 7.

    En réponse à David Flanagan qui s'inquiétait récemment du silence d'Oracle et de la stagnation du Project Lambda, Brian Goetz (Oracle) a soumis il y a quelques jours un document de réflexion sur la notion de virtual extension methods permettant d'ajouter sur une interface existante de nouvelles méthodes (avec des implémentations par défaut) sans casser le contrat avec le code existant.

    Exemple :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    public interface Set<T> extends Collection<T> { 
      public int size(); 
     
      // The rest of the existing Set methods 
      extension T reduce(Reducer<T> r) default Collections.<T>setReducer; 
    }
    Neal Gafter, l'un des principaux acteurs ces dernières années sur le thème des closures est resté relativement dubitatif :

    "The first is the ability to put default method implementations into an interface. The second is the ability to provide a method implementation by reference to another method. It isn't clear why one would intertwine the two proposals, and I don't understand the motivation for the latter (I don't buy the conclusion in the "Syntax Options" section). I'm guessing it is in part to simplify the implementation strategy, but that is a poor motivation…

    My most important comment is this: the relationship between this proposal and the (not well described) goals of project lambda are not clear. What software engineering techniques are you trying to enable, and for whom, and how does this proposal improve things? Without a clear explanation, this is a solution in search of a problem." --Neal Gafter
    De son côté, Stephen Colebourne, bien qu'exprimant son mécontentement sur la façon qu'avait Oracle de travailler dans son coin avant d'intervenir pour faire avancer le projet, a accueilli cette proposition de façon positive et a fait des retours :

    "I perfectly well understand that Oracle has met, discussed and decided to reject other options. The problem is that you've not done it /publicly/. As such, those of us outside Oracle are left with guessing at what thought processes you went through and reasoning you had. This makes it nigh on impossible to provide the meaningful feedback you'd like, or for you to win the trust of the broader community." --Stephen Colebourne
    Brian Goetz justifie sa proposition par la nécessité de s'inquiéter avant tout de la façon dont les APIs existantes pourront profiter des Closures, avant de chercher à mettre en oeuvre ces dernières.

    The intent of this feature is to render interfaces more malleable, allowing them to be extended over time by providing new methods so long as a default (which is restricted to using the public interface of the interface being extended) is provided. This addition to the language moves us a step towards interfaces being more like “mixins” or “traits”. However, developers may choose to start using this feature for new interfaces for reasons other than interface evolution.
    Brian Goetz
    C'est donc l'objet de ce document intitulé Interface evolution via “public defender” methods

    En sus, il a également produit un document davantage centré sur les Closures intitulé Translation of lambda expressions in javac

    Que pensez-vous de cette nouvelle approche ?
    Avez-vous l'impression que toutes ses réflexions vont porter leurs fruits ?

    Voir également :
    Le Projet Lambda
    Le Projet Coin (évolutions du langage) et vos impressions
    JDK 7 : Que pensez-vous des nouveautés et qu'auriez-vous aimé avoir de nouveau ?

  2. #2
    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 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Salut,


    Content de voir que tout cela ne tombe pas dans l'oubli !


    La notion de "virtual extension methods" est intéressante même si c'est à manier avec précaution car cela peut entrainer des incompatibilités.
    Le bon point c'est que cela doit être défini dans la définition de l'interface, et qu'on ne risque pas de voir des extensions partir dans tous les sens...


    C'est vrai que sans évolution des APIs, les évolutions du langage peuvent sembler inutile...


    a++

  3. #3
    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 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Le projet Lambda, poussé par Oracle a peut-être engendré un nouveau bébé, les "public defenders methods", dont l'objectif est de permettre de faire évoluer les interfaces Java.

    De prime abord cela n'a aucun lien avec les expressions lambdas (ou "closures"), mais l'intérêt étant de pouvoir réellement enrichir l'API avec ces dernières. En effet les interfaces étant figées, il est assez difficile de faire évoluer l'API : le simple ajout d'une nouvelle méthode entraine de nombreuses incompatibilités.

    Le rapport avec les expressions lambdas ? Ces dernières sont supposées simplifier et enrichir l'API, mais sont fortement limité par l'immuabilité des interfaces. Il fallait remettre cela en cause !

    » Lire la suite!

    Billet original publié sur les blogs de developpez.com...
    Billet original

  4. #4
    Membre habitué

    Profil pro
    Inscrit en
    Mai 2010
    Messages
    36
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 36
    Points : 163
    Points
    163
    Par défaut
    Techniquement, sur le fond, pourquoi pas: les public defender methods n'ont par l'air d'être une mauvaise idée. Je suis peut-être plus sceptique sur les pointeurs de fonction ... euh ... pardon, les virtual extension methods. Mais pourquoi pas.

    Quand à la mise en oeuvre des expressions lambda - j'ai du mal à comprendre qu'elle soit si difficile à adopter?


    Mais, ce que me gène plus, c'est la manière dont les choses se passent. C'est peut-être une idée que je me fais, mais vu de l'extérieur j'ai l'impression qu'Oracle essaye de reprendre la main sur Java. Non seulement au niveau du langage en incorporant de nouveaux concepts (plus ou moins repiqués de langages alternatifs?) mais aussi au niveau de la plate-forme. En effet, si j'ai bien compris, un certain nombre des modification annoncée entraîneraient l'ajout de nouvelles instructions à la JVM.

    Je suis peut-être mauvais esprit, mais je me dis que:
    (1) Oracle pourrait être tenté de faire évoluer le jeu d'instruction de la JVM pour (re)donner un avantage concurrentiel au langage Java au détriment des langages alternatifs
    (2) S'il y a effectivement une rapide évolution (lire: "sans consulter la communauté") de la JVM au cours des prochaines versions de Java, que va-t-il en être de la stabilité de la plate-forme? Ce qui par ailleurs pourrait mettre une pression insupportable sur les développeurs de versions alternatives de la JVM...


    Mes 0.02€
    - Sylvain

  5. #5
    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 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par sleroux Voir le message
    Non seulement au niveau du langage en incorporant de nouveaux concepts (plus ou moins repiqués de langages alternatifs?) mais aussi au niveau de la plate-forme.
    La plupart des fonctionnalités indiqué ici étaient déjà envisagés avant le rachat par Oracle. Par contre il semble que ce dernier veuille accélérer la cadence.

    Citation Envoyé par sleroux Voir le message
    En effet, si j'ai bien compris, un certain nombre des modification annoncée entraîneraient l'ajout de nouvelles instructions à la JVM.

    Je suis peut-être mauvais esprit, mais je me dis que:
    (1) Oracle pourrait être tenté de faire évoluer le jeu d'instruction de la JVM pour (re)donner un avantage concurrentiel au langage Java au détriment des langages alternatifs
    Au niveau des instructions du bytecode, il y a principalement l'ajout du invoke_dynamic, justement pour favoriser les langages de scripts au dessus d'une JVM


    a++

  6. #6
    Membre habitué

    Profil pro
    Inscrit en
    Mai 2010
    Messages
    36
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2010
    Messages : 36
    Points : 163
    Points
    163
    Par défaut
    Au niveau des instructions du bytecode, il y a principalement l'ajout du invoke_dynamic, justement pour favoriser les langages de scripts au dessus d'une JVM
    Oui, j'avais déjà vu ça. Et ça me semble une bonne idée. Par contre, j'avais cru comprendre que d'autres évolutions de la JVM étaient envisagées, justement pour les public defender methods:
    Citation Envoyé par http://blog.developpez.com/adiguba/p8947/java/7-dolphin/public-defenders-methods/#more8947
    Ces méthodes définissent une implémentation par défaut, il n'est donc pas obligatoire de les implémenter (même si cela reste possible). Ce nouveau cas particulier implique deux modifications distinctes du compilateur et le la machine virtuelle, afin de "rajouter" les méthodes absentes si besoin.
    C'est pour ça que je craignais une sorte de "surenchère":
    " Une nouvelle construction du langage Java?
    - Y'a qu'à modifier la JVM pour en faciliter la mise en oeuvre."
    Mais visiblement, j'ai mal compris - et j'ai un peu trop vite prêté des intentions douteuses à Oracle. Désolé

    Par contre il semble que ce dernier veuille accélérer la cadence.
    Sur la manière de faire, par "accélération", est-ce que ça signifie une remise en cause du "Java Community Process" au profit de décisions internes afin d'être plus réactif?

  7. #7
    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 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par sleroux Voir le message
    Oui, j'avais déjà vu ça. Et ça me semble une bonne idée. Par contre, j'avais cru comprendre que d'autres évolutions de la JVM étaient envisagées, justement pour les public defender methods:
    C'est pour ça que je craignais une sorte de "surenchère"
    Heu oui en effet il y a aussi de nouvelles fonctions dans la JVM (je pensais que tu parlais au niveau du bytecode). Toutefois cela n'est pas nouveau et cela a toujours été le cas à chaque évolution (assertion, enum, annotations, ...)

    Maintenant je ne pense pas que cela soit très problématique : ce n'est pas l'implémentation de la JVM qui posait problème, mais plutôt l'implémentation de toutes les classes de l'API, chose bien plus conséquente.
    Cela fait très longtemps qu'il existe des JVMs opensource (sans le runtime).


    Citation Envoyé par sleroux Voir le message
    Sur la manière de faire, par "accélération", est-ce que ça signifie une remise en cause du "Java Community Process" au profit de décisions internes afin d'être plus réactif?
    Ici aussi je ne sais pas si c'est lié à Oracle car cela s'amorçait déjà avant le rachat. On attend toujours plusieurs JSRs, dont celles du projet Coin, des expression lambda et surtout la JSR "release content" qui devra couvrir le contenu de Java 7...

    Reste à voir les raisons de cela. Peut être que Sun/Oracle souhaite proposer un document complet afin d'accélérer sa réalisation (je pense là à la JSR sur les Generics qui s'est étiré sur 5 années...)


    Il me semble avoir lu que ces JSRs étaient en préparation (au moins la JSR "release content" en tout cas). Je pense que c'est une obligation pour Sun/ORacle pour conserver le principe du "run everywhere". Sinon il pourrait s'attirer les foudres de la communauté...


    a++

  8. #8
    Membre chevronné
    Avatar de professeur shadoko
    Homme Profil pro
    retraité nostalgique Java SE
    Inscrit en
    Juillet 2006
    Messages
    1 257
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 76
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : retraité nostalgique Java SE

    Informations forums :
    Inscription : Juillet 2006
    Messages : 1 257
    Points : 1 855
    Points
    1 855
    Par défaut
    j'ai pas bien suivi : que se passe-t-il si on a ça dans un code préexistant:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
     
    class MaClasse implements Trucable {
     
        public int go() { //méthode qui n'a strictement rien à voir avec le contrat d'interface
        }
    }
    puis maintenant l'interface évolue ...;
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    interface Trucable {
        //méthodes habituelles
      extension int go() default UneClasse.doIt ;
    }
    comment se comporte la JVM qui rencontre un binaire de MaClasse non recompilé? (edit: normalement ...! du moins je l'espère, ma méthode go n'est pas reconnue à l'évaluation comme celle de l'interface ...)
    comment se comporte le compilo si on recompile MaClasse
    alors que la méthode préexistante n'a pas la sémantique voulue?
    Bien entendue MaClasse est "publiée" et utilisée par des tas d'autres programmes avant la modification de l'interface ....

    Bon il faut que je relise plus attentivement ....

Discussions similaires

  1. Tutoriel sur les nouveautés du langage 8 : le projet Lambda
    Par Mickael Baron dans le forum Langage
    Réponses: 7
    Dernier message: 21/03/2014, 13h04
  2. Réponses: 0
    Dernier message: 21/06/2007, 12h00
  3. [Oracle 9.2.0.7] Comment updater sur des clés de partition ?
    Par le_nullos_des_nullos dans le forum Oracle
    Réponses: 3
    Dernier message: 05/02/2006, 00h26
  4. Connexion depuis LAN impossible vers Mysql sur RH8
    Par RamDevTeam dans le forum Administration
    Réponses: 4
    Dernier message: 10/02/2005, 15h28

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