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:
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 :
Citation:
"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 :
Citation:
"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.
Citation:
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 :
:fleche: Le Projet Lambda
:fleche: Le Projet Coin (évolutions du langage) et vos impressions
:fleche: JDK 7 : Que pensez-vous des nouveautés et qu'auriez-vous aimé avoir de nouveau ?
