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 |
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;
} |
"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
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
"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
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
Brian Goetz
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 ? 
, 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.
Envoyé par sleroux
Cela fait très longtemps qu'il existe des JVMs opensource (sans le runtime).