JDK 7: Proposition 1 : Constructeurs simplifiés pour la généricité -> Intégrée [Débat]

[vbrabant]

27/08/2009 :
C'est fait : cette proposition a été intégré dans Java 7 sous le nom de "diamond syntax". Plus d'information sur http://blog.developpez.com/adiguba/p...iamond-syntax/

16/12/2007 :

Neal Gafter et Joshuah Bloch ont proposé lors d'un BOF qui s'est tenu à Javapolis 2007 certains changements au niveau du langage Java qui pourraient être introduits dans le JDK7. Le but ici est de recueillir vos votes et commentaires, de les consolider, et de les remonter à Neal Gafter et Joshuah Bloch.
D'autres JUG répartis un peu partout dans le monde feront de même. Ce qui permettra d'avoir le maximum de retour de la communauté Java.

Ne manquez pas cette chance unique de pouvoir donner votre avis concernant le futur de Java.

Aujourd'hui :

Code :

1
2
3
Map<String, List<String>> 
  anagrams = new HashMap<String, List<String>>();

Demain :

Code :

1
2
Map<String, List<String>> 
  anagrams = new HashMap<>();

[yann2]

Bonsoir

Je suis contre, mon IDE me fait la complétion automatiquement et si l'initialisation ne se fait pas en même temps que la déclaration, l'information portée par <String, List<String>> est pratique.

yann

[jibbi]

Je suis pour, en autant que l'initialisation actuelle reste disponible pour la même raison qu'a invoqué yann2.

[jowo]

Bonjour,

J'ai voté pour. Car si j'ai déjà déclaré le type de ma généricité, je ne vois pour quelle raison, je devrais le répéter pour l'instanciation.

[Napalm51]

Pour, mais en gardant à l'esprit la première remarque, à savoir que les 2 versions devraient être possible.

[n!co]

Voté pour,
Ca alège le code sans pour autant perdre vraiment de l'information à mes yeux.
D'autant que si je ne dis pas de bétise, seul l'information sur l'interface est réellement utile dans l'interprétation des générics par le compilateur.

[adiGuba]

Oui pour moi : cela permet d'éviter une répétition inutile...

Bien sûr quoi qu'il arrive la première syntaxe sera toujours valide (rien que pour assurer la compatibilité ascendante).

a++

[bobuse]

Envoyé par jibbi

Je suis pour, en autant que l'initialisation actuelle reste disponible pour la même raison qu'a invoqué yann2.

tout à fait pareil

[OButterlin]

pareil, même si ça n'est pas vital...

[bulbo]

Envoyé par yann2

Bonsoir

Je suis contre, mon IDE me fait la complétion automatiquement et si l'initialisation ne se fait pas en même temps que la déclaration, l'information portée par <String, List<String>> est pratique.

yann

Si tu as un IDE, celui ci t'informe aussi automatiquement si tu essayes de mettre des types incompatibles dans ton ArrayList.

J'ai voté pour, on ne perd pas d'information et ce n'est pas un sucre syntaxique qui a un cout a l'exécution (comme certains introduit par le passé) il évite juste la répétition d'une info inutile et qui n'était probablement pas utilisée par le compilo qui plus est..

Bulbo

[Muscador]

D'un premier abord, ça semble utile, mais ça ne favorise pas l'utilisation d'interfaces...

[eclesia]

pour, tant que l'autre ecriture reste possible pour certain cas.

[bulbo]

Envoyé par eclesia

pour, tant que l'autre ecriture reste possible pour certain cas.

Même si pour la compatibilité, l'autre écriture est bien nécessaire, je n'arrive pas a voir un cas ou cela aurait un intérêt.

Tu arriverais a nous filer un exemple ?

Muscador > Tu pourrais développer ta remarque sur les interfaces, je dois avouer que je suis passé a coté, je ne vois pas trop ce que les interfaces viennent faire la dedans..

Bulbo

[bobuse]

Envoyé par Muscador

D'un premier abord, ça semble utile, mais ça ne favorise pas l'utilisation d'interfaces...

Hmmm, tu es sûr ?
Tu as un exemple ?

[mavina]

pour, celà simplifie un peu la notation du typage

F.

[eclesia]

Envoyé par bulbo

Même si pour la compatibilité, l'autre écriture est bien nécessaire, je n'arrive pas a voir un cas ou cela aurait un intérêt.

Tu arriverais a nous filer un exemple ?

je pensais a ca :

Code :

1
2
3
 
Map mymap = new HashMap<Context,Layer>();        
traitement(mymap);

la définition des classes(<Context,Layer>) ce fait dans la deuxieme partie.
donc cette ecriture doit rester possible.

[adiGuba]

Pour moi c'est le type déclaré qui est important et non pas le type de la création , donc :

Code :

1
2
3
 
Map<Context,Layer> mymap = new HashMap();        
traitement(mymap);

Cela n'apporte rien de répéter le type lors de la création...

a++

[edit] je vois dans plusieurs sujets des remarques demandant à ce que les écritures actuelles restent utilisable : il n'y a aucun risque de suppression à ce niveau car cela impacterait la compatibilité ascendante...

[verbose]

Je suis plutôt pour, ça rendrait le code moins verbeux. La redondance n'apporte rien.

[bulbo]

Envoyé par eclesia

je pensais a ca :

Code :

la définition des classes(<Context,Layer>) ce fait dans la deuxieme partie.
donc cette ecriture doit rester possible.

Et tu as un beau warning a la compil car generic utilisé pour initialiser une variable non generic.
Perso je vire tout les warnings de mes projets quand je peux, et aucun warning ne vient de mon code si j'en laisse c'est que je n'ai pas le choix..
Ah oui j'oubliais a part le warning lors de l'affectation ton code n'utilisera absolument pas les generics pour checker le type des objets que tu mets dans ta HashMap.

Par contre si tu déclares ta variable avec les generic et que tu l'initialises avec un constructeur utilisant d'autres generic mais compatible avec ceux de la declaration, seuls ceux de la déclaration seront visibles au reste du programme, donc ceux du constructeur sont vraiment inutile.

Bulbo

[nicorama]

J'ai jamais compris à quoi servait cette redondance. Mon compilatuer marche très bien si je fais :
Vector <Eleve> listeEleves=new Vector();

Que je mette ou non <Eleve> dans la deuxième partie ne change rien. Est-ce que cela change à la compilation ?

Il y a même pire. Si je fais :

Code :

1
2
3
 
Vector <Eleve> listeEleves=new Vector();
listeEleves.add(prof);

Alors j'ai une erreur. Par contre si je fais :

Code :

1
2
3
4
5
6
 
Vector <Eleve> listeEleve;
    Vector <Professeur> listeProfesseur=new Vector<Professeur>();
    Vector a=new Vector();
    a=listeProfesseur;
    listeEleve=a;

Je n'ai pas d'erreur de compiltation, mais il y aura une errreur à l'execution. Je n'ai pourtant jamais mis les <> en double pour la listeEleve.

Bref, je ne vois pas pourquoi on ne se limiterais à Vector <Eleve> listeEleves=new Vector(); sans même rajouter <>

Je suppose qu'il doit y avoir une raison.

Si on les supprime complètement, je suis d'accord, mais sinon je suis contre : pour éviter d'avoir deux styles de notations (j'aime pas), et pour bien comprendre que Vector<Eleve> est un typage à part entière, qui n'hérite pas de Vector<Utilisateur>.