Les spécifications de Java SE 7 et 8 sont adoptées par le JCP, JDK 7 atteint le stade « Feature Complete »

[Idelways]

Le Java Community Process approuve à contrecœur Java SE 7
Des voix s'élèvent contre la politique de licence imposée par Oracle



Le scrutin sur Java SE 7 par le Java Community Process vient d'avoir lieu et d'approuver à la majorité écrasante cette prochaine édition standard du langage, mais non sans de nombreux commentaires fustigeant notamment la politique de licence menée par Oracle.

Google, bien que satisfait de l'avancement de la technologie sur cette version, mais visiblement décidé à gâcher la fête d'Oracle, a manifesté le seul vote négatif, contre 13 voix positives et 2 abstentions.

IBM, Red Hat, SouJava, London Java Community, Goldman Sachs et Fujitsu ont tous voté oui tout en affirmant dans les commentaires du vote leur refus de la politique de licence de Java, leur scepticisme envers le groupe d'experts et la transparence de tout le processus.

Sans mentionner le désaccord ayant conduit la fondation Apache à quitter le Process ni le procès en cours, Google rappelle que le kit de validation TCK (Technology Compatibility Kit), partie intégrante du standard, ne doit pas être utilisé pour interdire les implémentations compatibles, notamment dans le domaine du mobile.

L'éditeur d'Android, numéro 1 mondial des OS mobiles, juge que « les licences qui contiennent de telles restrictions sont incompatibles avec les exigences du JSPA, et violent les attentes de la communauté Java (sic) que les spécifications du JCP puissent être implémentées ouvertement ».

Werner Keil, expert en Java et membre à part entière du JCP, justifie son abstention par le « manque de transparence » tant dans la gestion de l'ensemble Umbrella JSR (Java Specification Request) que pour d'autres composants essentiels, en particulier le projet Coin.

Pour rappel, Java SE 7 offrira notamment une meilleure compatibilité avec les processeurs multicoeurs, des possibilités de scriptage dynamique, une API unifiée pour accéder aux systèmes du fichier de l'OS tout en continuant d’autoriser les opérations spécifiques à chaque plateforme.

Oracle, qui a naturellement voté oui sans commentaire, se heurte à de vives critiques qui ne se sont pas tassées malgré la volonté que le géant a récemment manifestée de révolutionner le fonctionnement du Java Community Process vers plus de transparence, de réactivité et d'agilité.


Source : JCP

Et vous ?

Que pensez-vous de la situation au sein du Java Community Process ?
Et de la progression de la technologie Java en général ?





OpenJDK 7 disponible en version bêta
Des voix s'élèvent contre sa licence jugée restrictive

Mise à jour du 28/02/2011 par Idelways


OpenJDK 7, le Kit de Développement du Java SE 7 est désormais disponible en version bêta (Milestone 12).

Les développeurs peuvent dès maintenant télécharger et s'assurer que leurs applications compilent et s'exécutent correctement sous cette version, et se familiariser ainsi avec les nouveautés du langage. La disponibilité générale de ce SDK est prévue dans exactement 5 mois.

Mark Reinhold, architecte en chef de la plateforme Java chez Oracle, explique que cette version a passé correctement tous les tests sur toutes les plates-formes. 456 bogues ont été corrigés depuis le Milestone 11 (déjà « Feature Complete »).

Une excellente nouvelle, mais gâchée pour certains par la licence jugée « draconienne et restrictive », « folle » voire carrément « antisociale » par certains utilisateurs qui se sont tout simplement refusés à tester le Kit sous ces conditions.

En effet, à la suite de l'annonce de Reinhold sur son blog, de nombreux commentaires affichent leur désarroi et leur déception.

Un utilisateur s'interroge sur les raisons de l'emploi d'une « licence qui empêche son utilisation par la large communauté qui [...] a aidé à la construire sur la base de code GPL d'OpenJDK » et inclut un lien vers un billet où il dresse la liste des sections qu'il juge « malveillantes ».

Un deuxième utilisateur se demande, ironique, s'il s'agit bien d'un projet open source et s'il est possible de télécharger le kit sans accepter cette « licence de fou ».

En plus de fustiger, entre autres, ce qu'il qualifie du désastre du projet Hudson et cette licence draconienne, un troisième utilisateur réprouve le Bug Tracker d'OpenJDK 7 qu'il juge complètement impraticable.

Quoi qu'il en soit, la majorité des utilisateurs qui se sont exprimés à la suite de cette annonce affichent leur enthousiasme de voir de langage Java 7 atteindre un autre cap important de son développement.


Cette version est disponible en téléchargement sur cette page

Source

Et vous ?

Que pensez-vous de cette preview d'OpenJDK 7 ?
Et de son contrat de licence ?



JDK 7 atteint le stade « Feature Complete »
Une bêta pour développeurs est prévue pour le 18 février prochain

Mise à jour du 19/01/2011 par Idelways



Oracle vient d’annoncer que le Kit de Développement de Java 7 (JDK7) est arrivé au stade « Feature Complete ».

Ce qui signifie, selon Henrik Ståhl, le porte-parole d'Oracle sur Java, que les équipes de développement et d'assurance-qualité ont finalisé toutes les fonctionnalités prévues pour Java 7 et que tous les tests automatisés passent.

Les efforts vont donc maintenant se concentrer sur les tests et la correction des bogues sur l'ensemble des plateformes supportées par JDK 7 afin qu'il soit disponible, si tout va bien, le 28 juillet prochain.

Ståhl n'exclut cependant pas l'ajout d'autres fonctionnalités aux sous-composants JAXP, JAXB et JAX-WS qui s'occupent respectivement de la manipulation du XML, du Binding et des WebServices.

Le projet pourrait aussi être retardé si le Groupe des Experts du JSR (Java Specification Request) "décident d'introduire des changements qui ne peuvent être accommodés avec le planning actuel", nous apprend Ståhl.

Si aucun empêchement ne vient retarder les plans d'Oracle, le JDK pourrait donc être disponible en bêta pour les développeurs dès le 17 février prochain. Soit dans moins d'un mois.

Une bonne nouvelle. Certes. Mais le respect du planning s'est fait au détriment de nombreuses fonctionnalités longtemps attendues et que les développeurs devront encore attendre avec Java 8, prévu lui pour l'année prochaine.

“On ne peut pas tout avoir”, dit le dicton.


Source : Billet de Henrik Ståhl

Et vous ?

Êtes-vous satisfait des nouveautés de Java 7 ou allez-vous attendre la sortie de Java 8 ?



Les spécifications de Java SE 7 et 8 proposées par Oracle sont adoptées
« À une écrasante majorité » par le Comité Exécutif du JCP

Mise à jour du 07/12/10



Oracle vient d'annoncer que ses propositions pour les spécifications des deux prochaines versions de la plate-forme Java (ses « Java Specification Requests » ou (JSR)) ont été adoptées après un vote du Comité Exécutif du JCP.

Oracle précise que ce vote, concernant les JSR 336 et 337, s'est soldé par une « écrasante majorité » en sa faveur, sans autre précision sur les chiffres du scrutin.

La feuille de route, désormais approuvée, prévoit une standardisation de Java SE 7 pour 2011 (le 28 juillet) et de Java SE 8 pour 2012.

« Java SE 7 inclut des changements du langage pour améliorer la productivité des développeurs, le renforcement du support des langages de scripts dynamiques et des améliorations de performances », rappelle Oracle. « Java SE 8 proposera des technologies pour améliorer la modularité du langage et le support des processeurs multicœurs » (lire ci-avant).

La Fondation Apache avait appelé à rejeter ces propositions. En cause, le kit de validation (TCK, non disponible en open source) qu'Oracle refuse de céder à la Fondation pour tester la compatibilité de son implémentation open source Harmony avec les spécifications du langage, ce qui l'empêche de la distribuer sous licence libre Apache.

Face à ce refus, la fondation Apache avait menacé de quitter le Java Community Process.

Après ce vote, sous forme de désaveu, l'avenir de sa participation au JCP semble donc se poser plus que jamais.



Source



MAJ de Gordon Fowler



Oracle annonce la sortie de Java 7 le 28 juillet 2011
Suivant le « plan B » : l'intégration des fonctions lambda et le projet Jigsaw reportés à Java 8

Mise à jour du 23/11/2010


En attendant le verdict du Java Community Process sur les propositions soumises la semaine passée, Oracle semble confiant quant à l'avenir du Langage Java sous sa responsabilité malgré les troubles causés par la Fondation Apache.

En effet, le géant des logiciels professionnels et des bases de données vient de publier une feuille de route précise qui aboutirait, si tout va comme Oracle et de nombreux développeurs le souhaitent, à la sortie générale du Kit de Développement de Java 7 (JDK) le 28 juillet 2011.

La prochaine étape de cette feuille de route sera la finalisation de la liste des fonctionnalités qui devrait être livrée par les ingénieurs d'Oracle le 16 décembre.

Pour respecter ces échéances, Oracle a dû revoir à la baisse ses ambitions pour Java 7 et appliquer ce qu'appelle Mark Reinhold (architecte en chef à Oracle) le « plan B ».

L'intégration des expressions Lambda, le projet Jigsaw et des parties du projet Coin attendront donc Java 8, prévu (si tout va bien) pour fin 2012.

Une décision assez pragmatique, mais qui ne manquerait pas de décevoir de nombreux développeurs. Java 7 arrivera avec 3 ans de retard. Et sans tenir toutes ses promesses.


Pour plus d'informations sur les nouveautés de Java 7 et 8, consultez le blog de adiGuba sur Developpez.com

Source : site de l'OpenJDK

Et vous ?

D'après vous, Oracle arrivera-t-il à sortir Java 7 dans 8 mois ?
Sans les fonctionnalités reportées, Java 7 vous semble-t-il toujours intéressant ?



Oracle soumet ses propositions pour Java 7 et 8
Le verdict du Java Community Process tombera dans deux semaines



Alors que le dialogue de sourds avec la Fondation Apache continue, Oracle, sans entorse à son planning, vient de soumettre sa proposition pour l'avenir du langage au Java Community Process, une proposition que la fondation Apache appelle tout bonnement à rejeter.

Ces spécifications, formulées en tant que « Java Specification Requests » (JSR) concernent les versions 7 et 8 de Java Standard Edition (Java SE).

Au menu, réduction du code passe-partout, le support de la programmation concurrente sur les processeurs multicœurs et le renforcement du support des langages de scripts dynamiques.

En plus des JSR 336 et 337 pour Java SE 7 et 8, deux autres documents de requêtes de spécifications ont été soumis : JSR 334, qui apporte des améliorations mineures du langage, censées faciliter la vie aux développeurs, et JSR 335, qui concerne l'introduction, tant attendue, des expressions lambda (closures) au langage.

Selon le texte de la proposition, ces nouvelles versions encourageraient les bonnes pratiques de développement, et réduiraient le recours au code passe-partout en ajoutant des fonctionnalités de productivité au langage proprement dit et aux API de Java SE.

Ces fonctionnalités devraient augmenter le niveau d'abstraction d'une manière "pragmatique" à en croire les specs d'Oracle, qui promet peu d'impact sur le code existant et une courbe d'apprentissage réduite.

Les membres du comité exécutif du Java Community Process voteront pour ou contre ces requêtes dans deux semaines.

Reste à savoir, donc, si Oracle peut en si peu de temps contenir la colère de la fondation Apache, qui semble plus déterminée que jamais à faire valoir ses droits.

Et à voter contre.


Consulter les requêtes de spécification 334, 335, 336, 337

Source : les blogs de Sun

Et vous ?

Que pensez-vous de la proposition d'Oracle ?
Le Java Community Process validera-t-il selon vous la proposition d'Oracle ?

En collaboration avec Gordon Fowler

[Joker-eph]

J'espère que le JCP va rejeter les propositions d'Oracle, non pas sur le fond mais bien sur la manière dont Oracle entend prendre la main. Oui ça retardera de quelques semaines/mois l'arrivée de Java 7 (et encore ça reste à voir...) mais au moins Oracle sera obligé d'adopter une attitude plus "fair" et moins arrogante vis à vis des autres partenaire qui contribuent à l'écosystème Java. Je pense que Java ne se portera que mieux avec un certain équilibre.

[stardeath]

je pense que si ces specs ne passent pas, ça sera l'occasion pour oracle de légitimement se débarrasser des membres gêneurs.

les propositions sont cohérentes, oracle sait pertinemment que si elles ne passent pas ça sera à cause de sa politique, mais, oracle a bien montrer qu'il n'en avait strictement rien à carrer de ceux qui ne rendent pas son commerce rentable. ça lui donnera juste des armes contre apache en prétextant qu'il veut pas que java évolue, apache est juste en train de se saborder lui même.

[bouye]

Cela fait trop longtemps que Java 7 est en retard, il est grand temps que les choses avancent. Au diable Apache et les guéguerres inter-opensource !

[Flaburgan]

Qu'est ce qui est reproché réellement à ces propositions ?

[_skip]

Envoyé par Flaburgan

Qu'est ce qui est reproché réellement à ces propositions ?

Aux propositions elles-mêmes, quasiment rien.
Les grévistes ne reprochaient rien aux raffineries, et pourtant ils les ont quand même bloquées pour faire pression. Ici c'est la même chose.

[Flaburgan]

Pénaliser la progression de Java juste pour essayer de faire entendre à tous qu'Oracle fait n'importe quoi ? Pas la meilleure idée qu'a eu apache...
J'ai envie de reprendre la comparaison en regardant les actions ridicules de tous ces manifestants face à un gouvernement qui fait la sourde oreille.
Le parallèle notre président / oracle me plaît beaucoup.

En attendant, tout le monde dans le monde IT sait déjà qu'Oracle est en train de mettre une belle pagaille, ce n'est donc pas pour avertir les gens qu'apache fait ça mais pour embêter Oracle. Et ça ne servira probablement à rien au final qu'à discréditer une fondation qui empêche la progression normal d'un projet. Mais que faire d'autre en même temps ?

[Uther]

Envoyé par Flaburgan

Qu'est ce qui est reproché réellement à ces propositions ?

Sur le fond rien, mais Apache a appelé les membres du JCP à refuser ces JSR tant que Oracle ne s'engage pas à fournir le TCK à toutes les JVM libres, comme il l'avait initialement promis. Actuellement, il ne le fournit que pour l'OpenJDK, et laisse volontairement Harmony à l'écart.
Le Tck est la suite de test permettant de certifier qu'un JRE est valide. Ça lui donne le droit d'utiliser le nom Java et le met à l’abri des brevets d'Oracle.

[camus3]

c'est donc un test pour Apache. L'avenir de Java va se jouer dans les prochaines semaines

[otabbakh]

J'espère aussi que la JCP refuse les propositions d'oracle.

[air-dex]

Enfin Java 7 va pouvoir sortir. Il serait dommage que Java continue à stagner à cause de guerres d'opinions. Pour une fois, le libre (ici par l'intermédiaire d'Apache) est plus un frein que le coup de boost qu'il a l'habitude d'être (technologies Mozilla, X.org, etc.).

Envoyé par JSR 334

This JSR will amend the Java programming language specification and API specification to support the following features:

- Strings in switch

Et c'est les mauvais développeurs qui ne connaissent pas les enums (valables dans les switch) qui gagneront le droit de coder légitiment avec les pieds. Je ne dis pas qu'il ne faut jamais utiliser les strings dans les switch, mais cette résolution est un beau nid à bugs avec des futures remarques du genre "je suis resté bloqué pendant deux jours sur ce bug à cause d'un 'e' en minuscules alors qu'il devait être en majuscules", évitables avec les énumérations.

L'introduction de l'amitié à la C++ aurait été beaucoup plus utile (relation étroite entre classes ne pouvant pas être dans le même package). J'ai déjà vécu personnellement cette situation et là j'ai pu voir que l'amitié ferait un bien fou à Java.

[Uther]

Envoyé par air-dex

Il serait dommage que Java continue à stagner à cause de guerres d'opinions. Pour une fois, le libre (ici par l'intermédiaire d'Apache) est plus un frein que le coup de boost qu'il a l'habitude d'être (technologies Mozilla, X.org, etc.).

Il faut relativiser. Ce n'est certainement pas le problème d'Harmony qui est la cause de la stagnation de Java ces dernières années. Apache a juste fait une opposition de forme au moment du vote final pour réclamer l’accès au TCK mais il ne s'est jamais opposé techniquement à l'évolution de Java.
C'est surtout le manque de moyen/ambition de Sun qui est à blâmer. Pas la peine d'aller imaginer des guéguerres la ou il n'y en a pas.

Envoyé par air-dex

L'introduction de l'amitié à la C++ aurait été beaucoup plus utile (relation étroite entre classes ne pouvant pas être dans le même package). J'ai déjà vécu personnellement cette situation et là j'ai pu voir que l'amitié ferait un bien fou à Java

A priori il y aura un mécanisme du genre avec les super-package, mais ils ne devraient pas arriver avant Java 8.

[air-dex]

Envoyé par Uther

C'est surtout le manque de moyen/ambition de Sun qui est à blâmer. Pas la peine d'aller imaginer des guéguerres la ou il n'y en a pas.

Soit pour le manque d'ambition, c'est même ce qui a causé la perte de Sun.

Mais là c'est quand même au moment où on peut enfin passer le cap de cette longue stagnation qu'Apache va au clash en freinant cette évolution salvatrice des deux pieds pour des querelles d'idées.

Espérons que cela rentre vite dans l'ordre pour le bien de Java, qui ne se remettrait peut-être pas de la perte d'outils comme Ant et Maven.

[Uther]

Envoyé par air-dex

Espérons que cela rentre vite dans l'ordre pour le bien de Java, qui ne se remettrait peut-être pas de la perte d'outils comme Ant et Maven.

Ant et Maven étant sous licence Apache, quoiqu'il arrive il ne disparaîtront pas, de plus la fondation Apache ne peut tout simplement pas abandonner tout le travail qu'elle a fait sur Java. D'ailleurs elle a commencé ce travail à une époque ou rien dans l'écosystème java n'était libre, et ça ne lui a pas posé de problème.

Quant au vote de la JSR de Java 7, il ne fait aucun doute pour moi qu'il passera, tout comme le vote de la JSR de JavaEE 6 est passé alors qu'Apache avait également fait un appel a voter contre pour les mêmes raisons.
Même s'il ne passait pas, ça créerait certainement des problème diplomatiques mais qui seraient de toute façon réglés en paralèle des problèmes techniques. Je ne pense pas que ça ralentirait la sortie de Java 7.

[Idelways]

Oracle annonce la sortie de Java 7 le 28 Juillet 2011
Suivant le « plan B » : l'intégration des fonctions lambda et le projet Jigsaw reportée à Java 8

Mise à jour du 23/11/2010


En attendant le verdict du Java Community Process sur les propositions soumises la semaine passée, Oracle semble confiant quant à l'avenir du Langage Java sous sa responsabilité malgré les troubles causés par la Fondation Apache.

En effet, le géant des logiciels professionnels et des bases de données vient de publier une feuille de route précise qui aboutirait, si tout va comme Oracle et de nombreux développeurs le souhaitent, à la sortie générale du Kit de Développement de Java 7 (JDK) le 28 Juillet 2011.

La prochaine étape de cette feuille de route sera la finalisation de la liste des fonctionnalités qui devrait être livrée par les ingénieurs d'Oracle le 16 décembre.

Pour respecter ces échéances, Oracle a du revoir à la baisse ses ambitions pour Java 7 et appliquer ce qu'appelle Mark Reinhold (architecte en chef à Oracle) le « plan B ».

L'intégration des expressions Lambda, le projet Jigsaw et des parties du projet Coin attendront donc Java 8, prévu (si tout va bien) pour fin 2012.

Une décision assez pragmatique, mais qui ne manquerait pas de décevoir de nombreux développeurs. Java 7 arrivera avec 3 ans de retard. Et sans tenir toutes ses promesses.


Pour plus d'informations sur les nouveautés de Java 7 et 8, consultez le blog de adiGuba sur Developpez.com

Source : site de l'OpenJDK

Et vous ?

D'après vous, Oracle arrivera-t-il a sortir Java 7 dans 8 mois ?
Sans les fonctionnalités reportées, Java 7 vous semble-t-il toujours intéressant ?

[_skip]

La liste mise à jour des features prévues se trouve ici :

http://openjdk.java.net/projects/jdk7/features/

Donc nous aurons quand même la majorité des améliorations de langage qui avaient été retenues à part la prise en charge des collections (opérateurs []). On aura tout de même le remplacement l'API file system préhistorique actuelle, par contre je me demande ou est passé la nouvelle API de Date/Time???

J'espérais naïvement qu'on aurait notre java7 courant/fin du premier trimestre 2011. Pour le reste, j'espère que java8 sera agrémenté de nouvelles propositions parce que les lambda c'est bien joli mais je pense personnellement que c'est qu'un léger plus pour 2 ans d'attente.

Au moins, oracle a le mérite de venir avec une roadmap, une date et du concret. On pouvait rêver mieux pour ce java7 qu'on annonçait il y a 2 ans comme une révolution mais c'est déjà ça de pris, on sait à peu près à quoi s'en tenir.

[Uther]

Envoyé par _skip

par contre je me demande ou est passé la nouvelle API de Date/Time???

Elle a été confirmée pour Java 8.

Envoyé par _skip

Pour le reste, j'espère que java 8 sera agrémenté de nouvelles propositions parce que les lambda c'est bien joli mais je pense personnellement que c'est qu'un léger plus pour 2 ans d'attente.

Il y aura au moins (confirmé dans la JSR de Java 8):
-le support des collections dans le langage
-les annotations sur les types
-la nouvelle API date
-la modularisation.

On parle éventuellement d'un support des properties dans le langage, mais je n'y crois pas vraiment.

Pour plus de détail:http://blog.developpez.com/adiguba/p...va-8/#more9504

[_skip]

Envoyé par Uther

On parle éventuellement d'un support des properties dans le langage, mais je n'y crois pas vraiment.

Alors là ce serait quelque chose! J'utilise actuellement Lombok (voir le lien actualité sous mon pseudo) pour simuler les propriétés mais il manque le support de la javadoc.
J'ai même réfléchi à écrire un plugin eclipse capable d'en générer dans une region donnée d'une classe java en utilisant une syntaxe spéciale en commentaire au dessus du membre pour spécifier la documentation.

Je trouve ça incompréhensible qu'on nous simplifie pas un peu plus la vie dans un langage qui oblige par convention l'utilisation des getter/setter.

[tomlev]

En voyant les nouveautés proposées dans Java 7, je peux pas m'empêcher de remarquer que Java se rapproche de plus en plus de C#... Une grande partie des nouveautés de cette version et de la prochaine existent déjà dans C# (je ne parle que des fonctionnalités du langage proprement dit, pas celles de la plateforme) :

• rethrow. Certes le problème est un peu différent en C# vu que les méthodes ne déclarent pas les exceptions qu'elle peuvent lancer... Par contre C# n'a pas le multi-catch, qui est un ajout intéressant
• switch sur les chaines de caractères
• inférence de type générique
• try-with-resources: c'est exactement la même chose que les blocs using de C#. Je suppose que les types utilisés avec cette syntaxe doivent implémenter une interface spécifique ? Ce n'est pas précisé dans l'article d'adiGuba
• expressions lambda (dommage que la syntaxe proposée soit un peu trop "verbeuse" par rapport à celle de C#)
• single abstract method : c'est apparemment l'équivalent d'un delegate en C# (d'ailleurs le terme "single abstract method" est mieux choisi, on comprend tout de suite de quoi il s'agit). La syntaxe proposée pour les références de méthodes est assez intéressante d'ailleurs : c'est moins concis qu'en C#, mais ça permet d'être beaucoup plus explicite, ce qui est est plutôt une bonne chose

En tous cas c'est bien de voir que Java continue d'évoluer, c'est juste dommage que ce soit pas plus rapide...

[adiGuba]

Salut,

Envoyé par tomlev

rethrow. Certes le problème est un peu différent en C# vu que les méthodes ne déclarent pas les exceptions qu'elle peuvent lancer...

Le problème n'existe pas en C# car il n'y a pas de notion de checked-exceptions. On peut donc rethrow n'importe quoi sans que cela ne pose problème...

Envoyé par tomlev

inférence de type générique

L'inférence existait déjà : Inferring Type Arguments Based on Actual Arguments
Elle a juste été amélioré notamment pour la syntaxe en losange et dans quelques cas très particulier)
(et ce sera encore amélioré avec les expressions lambda dans Java 8)

Envoyé par tomlev

try-with-resources: c'est exactement la même chose que les blocs using de C#. Je suppose que les types utilisés avec cette syntaxe doivent implémenter une interface spécifique ? Ce n'est pas précisé dans l'article d'adiGuba

Il suffira d'implémenter AutoCloseable

Envoyé par tomlev

expressions lambda (dommage que la syntaxe proposée soit un peu trop "verbeuse" par rapport à celle de C#)

La syntaxe n'est pas définitive et à déjà beaucoup changée (et rien ne dit que cela ne changera pas encore).
Pour info la version "courante" est décrite ici : State of the Lambda

Pour moi cela reste relativement proche de celle du C# :

Code :

1
2
3
4
5
// C# 3.0 :
myOperator multiply = (l, r) => l * r;
 
// Java 8 (version "courante") :
MyOperator multiply = {l, r -> l * r};

Après c'est sûr que la déclaration du delegate (myOperator) est plus succinct que la déclaration du type interface/classe SAM (MyOperator). :

Code :

1
2
3
4
5
6
7
// C# 3.0 :
delegate double myOperator(double l, double r);
 
// Java
interface MyOperator {
	double myOperator(double l, double r);
}

Quoique...

Envoyé par tomlev

single abstract method : c'est apparemment l'équivalent d'un delegate en C# (d'ailleurs le terme "single abstract method" est mieux choisi, on comprend tout de suite de quoi il s'agit)

Et cela permet également une compatibilité avec les APIs existantes, du moment qu'elles utilisent une interface/classe "SAM"...

Pas besoin de forcément faire une API spécifique pour cela. On pourra même utiliser les expressions lambda avec des API existantes

Envoyé par _skip

par contre je me demande ou est passé la nouvelle API de Date/Time???

Son report été déjà connu depuis bien longtemps...

Envoyé par _skip

Pour le reste, j'espère que java8 sera agrémenté de nouvelles propositions parce que les lambda c'est bien joli mais je pense personnellement que c'est qu'un léger plus pour 2 ans d'attente.

La proposition des "expressions Lambda" englobent également les "Method references" et des "Extension methods"



A ce propos j'aime bien l'exemple présente sur la page "State of the Lambda".


Pour trier une List<Person> par nom, actuellement on ferait ceci :

Code :

1
2
3
4
5
Collections.sort(people, new Comparator<Person>() {
	public int compare(Person x, Person y) {
		return x.getLastName().compareTo(y.getLastName());
	}
});

Avec les expressions lambda, on pourra utiliser ceci (sans toucher au code de Collections.sort()) :

Code :

1
2
Collections.sort(people, 
 	#{ Person x, Person y -> x.getLastName().compareTo(y.getLastName()) });

En créant une nouvelle méthode Collections.sortBy() plus adapté, cela pourrait devenir ceci :

Code :

Collections.sortBy(people, #{ Person p -> p.getLastName() });

Que l'on peut encore "réduire" en utilisant le "type inference" (le compilateur détermine le type du paramètre "p" de l'expression lambda) :

Code :

Collections.sortBy(people, #{ p -> p.getLastName() });

En utilisant les "Method References" cela devient ceci :

Code :

Collections.sortBy(people, Person#getLastName);

Enfin avec les "Extension methods la méthode sortBy() pourra être ajoutée directement à l'interface List<E>, ce qui nous donnerait :

Code :

people.sortBy(Person#getLastName);

a++