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

**nicorama** · 20/12/2007, 10h24

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Ce code marche très bien aujourd'hui, en tout cas sur mon PC.... Que faut t-il changer ?

**xavlours** · 20/12/2007, 10h59

J'ai voté pour, mais j'ai peur que ça complique encore la prise en main des generics.

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 ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Map<String, ? extends Collection<? extends Image>> map;
map = new HashMap<String, Set<BufferedImage>>();

Il faut préciser le type de la Map, ce qui est normal, mais qui n'est pas évident à comprendre au début.

Mais je vote pour.

**pierreact** · 20/12/2007, 17h42

Je suis pour et souhaite aussi que les deux syntaxes restent disponible...
Si cela est _impossible_... (Pas de raison, mais...) J'accepte quand meme, vu que le generique et l'instance ne sont que repetition de toutes facons...

**Uther** · 20/12/2007, 18h16

Je suis également pour et ne vois pas non plus l'interet du <>, vu que la généricité est seulement un sucre syntaxique.

**vbrabant** · 20/12/2007, 18h27

Envoyé par pierreact

Je suis pour et souhaite aussi que les deux syntaxes restent disponible...
Si cela est _impossible_... (Pas de raison, mais...) J'accepte quand meme, vu que le generique et l'instance ne sont que repetition de toutes facons...

Tout ce qui est proposé ici permettra toujours de code comme avant. On n'enlève rien. Les "anciennes" syntaxes seront toujours valides. On ne fait qu'en introduire de nouvelles.

Vincent

**pseudocode** · 29/12/2007, 01h50

J'ai voté contre.

1. Par principe, je suis pour la séparation du type de la variable et du type de l'instance. J'irai meme jusqu'a imposer que le type d'une variable soit toujours une interface.

2. Si le but c'est la lisibilité alors le gain est vraiment minime. Autant carrément supprimer le mot clé new et faire des allocations facon "C":

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
HashMap<String, List<String>> anagrams;

**deltree** · 21/03/2008, 11h11

Mais j'ai hésité entre l'avantage de simplifier la lisibilité, et de complexifier la compréhension de la grammaire Java (de moins en moins accessible)

Envoyé par pseudocode

1. Par principe, je suis pour la séparation du type de la variable et du type de l'instance. J'irai meme jusqu'a imposer que le type d'une variable soit toujours une interface.

2. Si le but c'est la lisibilité alors le gain est vraiment minime. Autant carrément supprimer le mot clé new et faire des allocations facon "C":

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
HashMap<String, List<String>> anagrams;

Dans l'idée de déclarer et instancier en une seule instruction j'avais aussi pensé à la syntaxe VB/LotusScript, qui a cependant ton inconvénient N°1: de ne pas utiliser d'interface:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
// pseudo VB de LotusScript
dim session as new Session()
 
//transposé en Java Generics
new HashMap<String,Person>(10) annuaire;

De toutes façon, je trouve que c'est une peu du "sucre" syntaxique,
est-ce qu'on ne pourrait pas carrément avoir un précompilateur comme en C, avec des des %Define et des typedefs, pour alléger les types trops longs à écrire?
ça remplirait finalement la même fonction.

**jakkk** · 14/02/2008, 22h37

dans l'exemple qui est donné je ne suis pas tellement gêné par la répétition, c'est plus l'absence de désignation de ce générique qui est problématique!

à la place de

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

Je préférai:

generic <String, List<String>> AnagramItem;
...
Map<AnagramItem> anagrams = new HashMap<AnagramItem>();

ce qui permettrait de facilement remplacer un type générique partout,

de faire de l'introspection sur les types génériques ...

**bouye** · 14/02/2008, 23h45

Pas vraiment non car pouvoir faire de la reflection suppose que le bytecode stocke quelque part une information sur le type utilise ce qui n'est actuellement pas le cas (dans leur implementation actuelle, les generics ne sont que du sucre syntaxique pre-compilation pour eviter les casts manuels) sans que le programmeur ne s'en charge lui-meme.

Par contre, un typedef ou equivalent n'etait-il pas en discussion pour cette release ou une suivante ???

**fisico** · 07/05/2008, 11h35

contre, l'apport de l'innovation ne change pas grand chose, même rien du tout. on a pris l'habitude de travailler ainsi.

**emile.coue** · 07/05/2008, 11h59

Je suis contre, tant qu'il y a la mécanique d'autocomplétion dans la majorité des IDEs, cette forme d'instantiation ne va ajouter que de difficultés au niveau de la lisibilité du code et le rendre moins compréhensible sur tout quand elle est loin de la déclaration de la référence.

**adiGuba** · 07/05/2008, 12h20

Envoyé par emile.coue

cette forme d'instantiation ne va ajouter que de difficultés au niveau de la lisibilité du code et le rendre moins compréhensible sur tout quand elle est loin de la déclaration de la référence.

De la manière dont je l'ai compris, ce ne serait possible que dans le cas d'une instantiation en ligne... un peut comme pour les tableaux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
	int[] values = { 1, 2, 3, 4 }; // OK
 
	values = { 1, 2, 3, 4 }; // ERREUR
	values = new int[] { 1, 2, 3, 4 }; // OK

a++

**elitost** · 19/12/2007, 18h58

Egalement pour, et pour les mêmes raisons citées précedemment, redondance d'information, mais pour garder les 2 notations

**bouye** · 19/12/2007, 22h57

Oui MAIS quel est l'interet de mettre <> dans l'appel au contructeur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Ceci serait mieux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Pour le reste, l'information type est deja convoye dans la partie gauche de l'affectation.

**natha** · 20/12/2007, 09h00

Voté "pour" pour toutes les raisons évoquées.

Envoyé par bouye

Oui MAIS quel est l'interet de mettre <> dans l'appel au contructeur.

Je me pose la même question. Aucun intérêt de toute façon.

**romaintaz** · 20/12/2007, 09h04

Envoyé par bouye

Oui MAIS quel est l'interet de mettre <> dans l'appel au contructeur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Ceci serait mieux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

En effet, c'est clair que je ne vois pas l'intérêt d'ajouter le <> ...

**ludosoft** · 20/12/2007, 10h39

Envoyé par bouye

Oui MAIS quel est l'interet de mettre <> dans l'appel au contructeur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Ceci serait mieux :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Pour le reste, l'information type est deja convoye dans la partie gauche de l'affectation.

Je pense qu'il ne faut pas trop en enlever non plus hein... Le fait de mettre "<>" indique clairement à l'oeil que ce n'est pas une "simple HashMap" qui est instanciée.

Et ça ferait quoi ce code là ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

**Alec6** · 20/12/2007, 10h42

Milles excuses c'est vrai que les générics n'acceptent pas l'heritage et on ne peut pas faire de polymorphisme avec.

Snif.

**bouye** · 20/12/2007, 22h13

Envoyé par ludosoft

Je pense qu'il ne faut pas trop en enlever non plus hein... Le fait de mettre "<>" indique clairement à l'oeil que ce n'est pas une "simple HashMap" qui est instanciée.

Ben si justement, c'est tout la le probleme, ca ne reste que du sucre syntaxique au final on a bien une map toute simple et le compilateur qui met des cast la ou il faut dans le bytecode (en gros la ou on les mettait manuellement en java 1.4-). Donc aucune difference avec la creation d'une Map<Object, Object>.

Et ça ferait quoi ce code là ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

On peut deja faire sans aucun probleme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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

Il est possible de caster HashMap<Object, Object> en Map<String, List<String>> et de recaster cette derniere en Map<Object, Object> . On a juste le warning habituel :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Note: test\TestCast.java uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
test\TestCast.java:24: warning: [unchecked] unchecked cast
found   : java.util.HashMap
required: java.util.Map<java.lang.String,java.util.List<java.lang.String>>
    Map anagrams = (Map<String, List<String>>)new HashMap();
                                              ^
1 warning