Discussion :

[Ricky81]

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 ?

[adiGuba]

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++

[adiGuba]

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

[sleroux]

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

[adiGuba]

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.

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++

[sleroux]

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:

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?

[adiGuba]

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).

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++

[professeur shadoko]

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 ....