Oracle annonce la sortie de Java 7 le 28 juillet 2011
L'intégration des expressions lambda et le projet Jigsaw reportée à Java 8

Le , par Idelways, Expert éminent sénior
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse Signaler un problème

Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 23/11/2010 à 12:11
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.
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 23/11/2010 à 12:30
Citation 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.

Citation 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
Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 23/11/2010 à 13:09
Citation 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.
Avatar de tomlev tomlev - Rédacteur/Modérateur https://www.developpez.com
le 23/11/2010 à 14:30
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...
Avatar de adiGuba adiGuba - Expert éminent sénior https://www.developpez.com
le 23/11/2010 à 15:21
Salut,

Citation Envoyé par tomlev Voir le message
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...

Citation Envoyé par tomlev Voir le message
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)

Citation Envoyé par tomlev Voir le message
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

Citation Envoyé par tomlev Voir le message
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 : Sélectionner tout
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 : Sélectionner tout
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...

Citation Envoyé par tomlev Voir le message
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

Citation Envoyé par _skip Voir le message
par contre je me demande ou est passé la nouvelle API de Date/Time???
Son report été déjà connu depuis bien longtemps...

Citation Envoyé par _skip Voir le message
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 : Sélectionner tout
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 : Sélectionner tout
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 : Sélectionner tout
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 : Sélectionner tout
Collections.sortBy(people, #{ p -> p.getLastName() });
En utilisant les "Method References" cela devient ceci :
Code : Sélectionner tout
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 : Sélectionner tout
people.sortBy(Person#getLastName);

a++
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 23/11/2010 à 15:23
Citation Envoyé par _skip Voir le message
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.
Moi aussi, je l'attend depuis très longtemps, mais vu que ça n'a pas encore été réellement mis sur la table, je doute que ça soit prêt pour Java 8

Citation Envoyé par tomlev Voir le message
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
Oui il y aura l'interface AutoCloseable à implémenter pour cela.

Citation Envoyé par tomlev Voir le message
expressions lambda (dommage que la syntaxe proposée soit un peu trop "verbeuse" par rapport à celle de C#)
Personnellement, je trouve la syntaxe C# trop courte. D'habitude j'aime faire court, mais enfermer un lambda entre accolade,prenthèse,... me semble un minimum pour rester lisible.

Je préfèrais la première syntaxe proposé pour les lambda Java #(x){x*x}; à la dernière: #{x->x*x} . Elle collait plus à ce que l'on voit habituellement en Java(paramètres entre parenthèse, code dans le bloc).
J'ai du mal à voir pourquoi rajouter un nouveau symbole "->" qui en plus ne me parait pas vraiment adapté car il n'y a pas vraiment de pas de notion de déplacement.
Avatar de tomlev tomlev - Rédacteur/Modérateur https://www.developpez.com
le 23/11/2010 à 15:31
@adiGuba, merci pour les précisions

Citation Envoyé par adiGuba  Voir le message
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 : Sélectionner tout
1
2
3
4
5
// C# 3.0 : 
myOperator multiply = (l, r) => l * r; 
 
// Java 8 (version "courante") : 
MyOperator multiply = {l, r -> l * r};

Effectivement, c'est mieux
Ce que j'avais vu semblait nettement plus lourd...

Citation Envoyé par Uther  Voir le message
Personnellement, je trouve la syntaxe C# trop courte. D'habitude j'aime faire court, mais enfermer un lambda entre accolade,prenthèse,... me semble un minimum pour rester lisible.

Je pense que c'est une question d'habitude... dans les cas simples, c'est parfaitement compréhensible avec la syntaxe "compacte". Mais rien n'empêche d'être plus explicite :

Code C# : Sélectionner tout
1
2
3
4
5
// Cette instruction : 
Func<Foo, string> selector = f => f.Name; 
  
// Est équivalente (sémantiquement) à : 
Func<Foo, string> selector = (Foo f) => { return f.Name; };
Avatar de Uther Uther - Expert éminent https://www.developpez.com
le 23/11/2010 à 15:33
Citation Envoyé par adiGuba
// Java 8 (version "courante" :
MyOperator multiply = {l, r -> l * r};
La dernière fois que j'avais noté un changement, il me semble bien qu'il fallait encore un # devant le bloc.
C'est un oubli ou ça encore changé?
Avatar de _skip _skip - Expert éminent https://www.developpez.com
le 23/11/2010 à 15:35
Citation Envoyé par adiGuba Voir le message

Son report été déjà connu depuis bien longtemps...
Ca commençait à devenir difficile de savoir ce qu'ils brassaient franchement...

Citation Envoyé par Uther
Moi aussi, je l'attend depuis très longtemps, mais vu que ça n'a pas encore été réellement mis sur la table, je doute que ça soit prêt pour Java 8
En 2018 ça devrait être bon...
Avatar de adiGuba adiGuba - Expert éminent sénior https://www.developpez.com
le 23/11/2010 à 15:40
Citation Envoyé par Uther Voir le message
La dernière fois que j'avais noté un changement, il me semble bien qu'il fallait encore un # devant le bloc.
C'est un oubli ou ça encore changé?
Non c'est un oubli de ma part en effet :
Code : Sélectionner tout
1
2
3
4
5
// C# 3.0 :
myOperator multiply = (l, r) => l * r;

// Java 8 (version "courante") :
MyOperator multiply = #{l, r -> l * r};
Par contre comme je l'ait dit et comme le signale tomlev il y a du type-inference ce qui fait qu'on n'a pas forcément besoin de déclarer les types des paramètres. En clair c'est équivalent à ceci :
Code : Sélectionner tout
1
2
3
4
5
// C# 3.0 :
myOperator multiply = (double l, double r) => l * r;

// Java 8 (version "courante") :
MyOperator multiply = #{double l, double r -> l * r};
Mais il ne faut pas vraiment s'attarder sur la syntaxe. L'objectif actuel du projet Lambda est de proposer un prototype complet et fonctionnel. Les débats sur la syntaxe auront lieu plus tard...

a++
Contacter le responsable de la rubrique Accueil