//Quand je fais :
Voiture maVoiture;
Map<String,Voiture> immatriculationVoitureMap =3D new
HashMap<String,Voiture>();
immatriculation.put("1234WW75",maVoiture);
maVoiture =3D immatriculation.get("1234WW75");
// =E7a marche ... normal
//Quand je fais :
Girafe girafe =3D new Girafe();
maVoiture =3D immatriculation.get(girafe);
// Il gueule ... normal
// Maintenant, je complique un peu :
Roue uneRoue;
Map<String,Map<String,Roue>> immatriculationPositionRoueVoitureMap =3D
new
HashMap<String,Map<String,Roue>>();
immatriculationPositionRoueVoitureMap.put("1234WW75", new
HashMap<String,Roue>);
immatriculationPositionRoueVoitureMap.get("1234WW75").put("AvantDroit",
uneRoue);
uneRoue =3D
immatriculationPositionRoueVoitureMap.get("1234WW75").get("AvantDroit");
// =E7a marche ... normal
// Mais quand je fais :
Girafe girafe =3D new Girafe();
uneRoue =3D
immatriculationPositionRoueVoitureMap.get("1234WW75").get(girafe);
// uneRoue re=E7oit null, mais sans erreur : pas de d=E9tection de
mauvais type.
Votre avis : Normal ? Bug ? Mauvaise utilisation ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
TestMan
Bonjour,
//Quand je fais : Voiture maVoiture; Map<String,Voiture> immatriculationVoitureMap = new HashMap<String,Voiture>(); immatriculation.put("1234WW75",maVoiture); maVoiture = immatriculation.get("1234WW75"); // ça marche ... normal //Quand je fais : Girafe girafe = new Girafe(); maVoiture = immatriculation.get(girafe); // Il gueule ... normal
// Maintenant, je complique un peu : Roue uneRoue; Map<String,Map<String,Roue>> immatriculationPositionRoueVoitureMap > new HashMap<String,Map<String,Roue>>(); immatriculationPositionRoueVoitureMap.put("1234WW75", new HashMap<String,Roue>); immatriculationPositionRoueVoitureMap.get("1234WW75").put("AvantDroit", uneRoue); uneRoue > immatriculationPositionRoueVoitureMap.get("1234WW75").get("AvantDroit"); // ça marche ... normal // Mais quand je fais : Girafe girafe = new Girafe(); uneRoue > immatriculationPositionRoueVoitureMap.get("1234WW75").get(girafe); // uneRoue reçoit null, mais sans erreur : pas de détection de mauvais type.
Votre avis : Normal ? Bug ? Mauvaise utilisation ?
J'utilise java 1.5.0_07
Bonsoir,
Sur le JDK1.5.0, la signature de .get() est :
V get(Object key);
et pas :
V get(K key);
Donc, le comportement est bien "normal" ... c'est un choix assumé (il y a eut un débat sur le bug parade).
En gros, l'argument était que dans le cas d'un Map<Number, String> mettre la clé en paramétrique empècherait d'avoir map.get(new Integer(0)) ! Ce qui est faux, car si l'on souhaite autoriser les classe dérivant à être paramètre, il suffit d'utiliser le type : Map<? extends Number, String>
Une nouvelle passe sur les API afin de vérifier leur conformité vis-à-vis de la généricité s'impose :o)
Pourra-t-elle être faite dans le cadre du JDK6 ? Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine béta ;-)
Un peu de lecture simpa pour les insomniaques : http://java.sun.com/docs/books/tutorial/extra/generics/index.html
A+ TM
Bonjour,
//Quand je fais :
Voiture maVoiture;
Map<String,Voiture> immatriculationVoitureMap = new
HashMap<String,Voiture>();
immatriculation.put("1234WW75",maVoiture);
maVoiture = immatriculation.get("1234WW75");
// ça marche ... normal
//Quand je fais :
Girafe girafe = new Girafe();
maVoiture = immatriculation.get(girafe);
// Il gueule ... normal
// Maintenant, je complique un peu :
Roue uneRoue;
Map<String,Map<String,Roue>> immatriculationPositionRoueVoitureMap > new
HashMap<String,Map<String,Roue>>();
immatriculationPositionRoueVoitureMap.put("1234WW75", new
HashMap<String,Roue>);
immatriculationPositionRoueVoitureMap.get("1234WW75").put("AvantDroit",
uneRoue);
uneRoue > immatriculationPositionRoueVoitureMap.get("1234WW75").get("AvantDroit");
// ça marche ... normal
// Mais quand je fais :
Girafe girafe = new Girafe();
uneRoue > immatriculationPositionRoueVoitureMap.get("1234WW75").get(girafe);
// uneRoue reçoit null, mais sans erreur : pas de détection de
mauvais type.
Votre avis : Normal ? Bug ? Mauvaise utilisation ?
J'utilise java 1.5.0_07
Bonsoir,
Sur le JDK1.5.0, la signature de .get() est :
V get(Object key);
et pas :
V get(K key);
Donc, le comportement est bien "normal" ... c'est un choix assumé (il y
a eut un débat sur le bug parade).
En gros, l'argument était que dans le cas d'un Map<Number, String>
mettre la clé en paramétrique empècherait d'avoir map.get(new
Integer(0)) ! Ce qui est faux, car si l'on souhaite autoriser les classe
dérivant à être paramètre, il suffit d'utiliser le type :
Map<? extends Number, String>
Une nouvelle passe sur les API afin de vérifier leur conformité
vis-à-vis de la généricité s'impose :o)
Pourra-t-elle être faite dans le cadre du JDK6 ?
Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine
béta ;-)
Un peu de lecture simpa pour les insomniaques :
http://java.sun.com/docs/books/tutorial/extra/generics/index.html
//Quand je fais : Voiture maVoiture; Map<String,Voiture> immatriculationVoitureMap = new HashMap<String,Voiture>(); immatriculation.put("1234WW75",maVoiture); maVoiture = immatriculation.get("1234WW75"); // ça marche ... normal //Quand je fais : Girafe girafe = new Girafe(); maVoiture = immatriculation.get(girafe); // Il gueule ... normal
// Maintenant, je complique un peu : Roue uneRoue; Map<String,Map<String,Roue>> immatriculationPositionRoueVoitureMap > new HashMap<String,Map<String,Roue>>(); immatriculationPositionRoueVoitureMap.put("1234WW75", new HashMap<String,Roue>); immatriculationPositionRoueVoitureMap.get("1234WW75").put("AvantDroit", uneRoue); uneRoue > immatriculationPositionRoueVoitureMap.get("1234WW75").get("AvantDroit"); // ça marche ... normal // Mais quand je fais : Girafe girafe = new Girafe(); uneRoue > immatriculationPositionRoueVoitureMap.get("1234WW75").get(girafe); // uneRoue reçoit null, mais sans erreur : pas de détection de mauvais type.
Votre avis : Normal ? Bug ? Mauvaise utilisation ?
J'utilise java 1.5.0_07
Bonsoir,
Sur le JDK1.5.0, la signature de .get() est :
V get(Object key);
et pas :
V get(K key);
Donc, le comportement est bien "normal" ... c'est un choix assumé (il y a eut un débat sur le bug parade).
En gros, l'argument était que dans le cas d'un Map<Number, String> mettre la clé en paramétrique empècherait d'avoir map.get(new Integer(0)) ! Ce qui est faux, car si l'on souhaite autoriser les classe dérivant à être paramètre, il suffit d'utiliser le type : Map<? extends Number, String>
Une nouvelle passe sur les API afin de vérifier leur conformité vis-à-vis de la généricité s'impose :o)
Pourra-t-elle être faite dans le cadre du JDK6 ? Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine béta ;-)
Un peu de lecture simpa pour les insomniaques : http://java.sun.com/docs/books/tutorial/extra/generics/index.html
A+ TM
gvauvert
Pourra-t-elle être faite dans le cadre du JDK6 ? Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine béta ;-) Mouais, je pense que la libération sera une "conditionnelle", et que
la 6 sortira avant (pour bonne conduite).
Un peu de lecture simpa pour les insomniaques : http://java.sun.com/docs/books/tutorial/extra/generics/index.html Lien très intéressant. On comprend bien le pourquoi des interdits.
Merci pour cette réponse claire.
Guillaume
Pourra-t-elle être faite dans le cadre du JDK6 ?
Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine
béta ;-)
Mouais, je pense que la libération sera une "conditionnelle", et que
la 6 sortira avant (pour bonne conduite).
Un peu de lecture simpa pour les insomniaques :
http://java.sun.com/docs/books/tutorial/extra/generics/index.html
Lien très intéressant. On comprend bien le pourquoi des interdits.
Pourra-t-elle être faite dans le cadre du JDK6 ? Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine béta ;-) Mouais, je pense que la libération sera une "conditionnelle", et que
la 6 sortira avant (pour bonne conduite).
Un peu de lecture simpa pour les insomniaques : http://java.sun.com/docs/books/tutorial/extra/generics/index.html Lien très intéressant. On comprend bien le pourquoi des interdits.
Merci pour cette réponse claire.
Guillaume
Kupee
Bonjour,
//Quand je fais : Voiture maVoiture; Map<String,Voiture> immatriculationVoitureMap = new HashMap<String,Voiture>(); immatriculation.put("1234WW75",maVoiture); maVoiture = immatriculation.get("1234WW75"); // ça marche ... normal //Quand je fais : Girafe girafe = new Girafe(); maVoiture = immatriculation.get(girafe); // Il gueule ... normal
// Maintenant, je complique un peu : Roue uneRoue; Map<String,Map<String,Roue>> immatriculationPositionRoueVoitureMap >> new HashMap<String,Map<String,Roue>>(); immatriculationPositionRoueVoitureMap.put("1234WW75", new HashMap<String,Roue>); immatriculationPositionRoueVoitureMap.get("1234WW75").put("AvantDroit", uneRoue); uneRoue >> immatriculationPositionRoueVoitureMap.get("1234WW75").get("AvantDroit"); // ça marche ... normal // Mais quand je fais : Girafe girafe = new Girafe(); uneRoue >> immatriculationPositionRoueVoitureMap.get("1234WW75").get(girafe); // uneRoue reçoit null, mais sans erreur : pas de détection de mauvais type.
Votre avis : Normal ? Bug ? Mauvaise utilisation ?
J'utilise java 1.5.0_07
Bonsoir,
Sur le JDK1.5.0, la signature de .get() est :
V get(Object key);
et pas :
V get(K key);
Donc, le comportement est bien "normal" ... c'est un choix assumé (il y a eut un débat sur le bug parade).
En gros, l'argument était que dans le cas d'un Map<Number, String> mettre la clé en paramétrique empècherait d'avoir map.get(new Integer(0)) ! Ce qui est faux, car si l'on souhaite autoriser les classe dérivant à être paramètre, il suffit d'utiliser le type : Map<? extends Number, String>
Une nouvelle passe sur les API afin de vérifier leur conformité vis-à-vis de la généricité s'impose :o)
Pourra-t-elle être faite dans le cadre du JDK6 ? Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine béta ;-)
Un peu de lecture simpa pour les insomniaques : http://java.sun.com/docs/books/tutorial/extra/generics/index.html
le get(Object) a peut etre une raison, cela évite de faire des cast non nécéssaires a mon avis. Et je pense pas qu'ils changent ca, car cela interdirait de compiler le code écrit en jdk 1.5 avec un jdk qui modifierait ce comportement
Bonjour,
//Quand je fais :
Voiture maVoiture;
Map<String,Voiture> immatriculationVoitureMap = new
HashMap<String,Voiture>();
immatriculation.put("1234WW75",maVoiture);
maVoiture = immatriculation.get("1234WW75");
// ça marche ... normal
//Quand je fais :
Girafe girafe = new Girafe();
maVoiture = immatriculation.get(girafe);
// Il gueule ... normal
// Maintenant, je complique un peu :
Roue uneRoue;
Map<String,Map<String,Roue>> immatriculationPositionRoueVoitureMap >> new
HashMap<String,Map<String,Roue>>();
immatriculationPositionRoueVoitureMap.put("1234WW75", new
HashMap<String,Roue>);
immatriculationPositionRoueVoitureMap.get("1234WW75").put("AvantDroit",
uneRoue);
uneRoue >> immatriculationPositionRoueVoitureMap.get("1234WW75").get("AvantDroit");
// ça marche ... normal
// Mais quand je fais :
Girafe girafe = new Girafe();
uneRoue >> immatriculationPositionRoueVoitureMap.get("1234WW75").get(girafe);
// uneRoue reçoit null, mais sans erreur : pas de détection de
mauvais type.
Votre avis : Normal ? Bug ? Mauvaise utilisation ?
J'utilise java 1.5.0_07
Bonsoir,
Sur le JDK1.5.0, la signature de .get() est :
V get(Object key);
et pas :
V get(K key);
Donc, le comportement est bien "normal" ... c'est un choix assumé (il y
a eut un débat sur le bug parade).
En gros, l'argument était que dans le cas d'un Map<Number, String>
mettre la clé en paramétrique empècherait d'avoir map.get(new
Integer(0)) ! Ce qui est faux, car si l'on souhaite autoriser les classe
dérivant à être paramètre, il suffit d'utiliser le type :
Map<? extends Number, String>
Une nouvelle passe sur les API afin de vérifier leur conformité
vis-à-vis de la généricité s'impose :o)
Pourra-t-elle être faite dans le cadre du JDK6 ?
Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine
béta ;-)
Un peu de lecture simpa pour les insomniaques :
http://java.sun.com/docs/books/tutorial/extra/generics/index.html
le get(Object) a peut etre une raison, cela évite de faire des cast non
nécéssaires a mon avis. Et je pense pas qu'ils changent ca, car cela
interdirait de compiler le code écrit en jdk 1.5 avec un jdk qui
modifierait ce comportement
//Quand je fais : Voiture maVoiture; Map<String,Voiture> immatriculationVoitureMap = new HashMap<String,Voiture>(); immatriculation.put("1234WW75",maVoiture); maVoiture = immatriculation.get("1234WW75"); // ça marche ... normal //Quand je fais : Girafe girafe = new Girafe(); maVoiture = immatriculation.get(girafe); // Il gueule ... normal
// Maintenant, je complique un peu : Roue uneRoue; Map<String,Map<String,Roue>> immatriculationPositionRoueVoitureMap >> new HashMap<String,Map<String,Roue>>(); immatriculationPositionRoueVoitureMap.put("1234WW75", new HashMap<String,Roue>); immatriculationPositionRoueVoitureMap.get("1234WW75").put("AvantDroit", uneRoue); uneRoue >> immatriculationPositionRoueVoitureMap.get("1234WW75").get("AvantDroit"); // ça marche ... normal // Mais quand je fais : Girafe girafe = new Girafe(); uneRoue >> immatriculationPositionRoueVoitureMap.get("1234WW75").get(girafe); // uneRoue reçoit null, mais sans erreur : pas de détection de mauvais type.
Votre avis : Normal ? Bug ? Mauvaise utilisation ?
J'utilise java 1.5.0_07
Bonsoir,
Sur le JDK1.5.0, la signature de .get() est :
V get(Object key);
et pas :
V get(K key);
Donc, le comportement est bien "normal" ... c'est un choix assumé (il y a eut un débat sur le bug parade).
En gros, l'argument était que dans le cas d'un Map<Number, String> mettre la clé en paramétrique empècherait d'avoir map.get(new Integer(0)) ! Ce qui est faux, car si l'on souhaite autoriser les classe dérivant à être paramètre, il suffit d'utiliser le type : Map<? extends Number, String>
Une nouvelle passe sur les API afin de vérifier leur conformité vis-à-vis de la généricité s'impose :o)
Pourra-t-elle être faite dans le cadre du JDK6 ? Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine béta ;-)
Un peu de lecture simpa pour les insomniaques : http://java.sun.com/docs/books/tutorial/extra/generics/index.html
le get(Object) a peut etre une raison, cela évite de faire des cast non nécéssaires a mon avis. Et je pense pas qu'ils changent ca, car cela interdirait de compiler le code écrit en jdk 1.5 avec un jdk qui modifierait ce comportement
gvauvert
le get(Object) a peut etre une raison, cela évite de faire des cast non nécéssaires a mon avis. Un exemple pour illustrer ça ?
Et je pense pas qu'ils changent ca, car cela interdirait de compiler le code écrit en jdk 1.5 avec un jdk qui modifierait ce comportement C'est là tout l'intérêt des versions majeures : on a le droit de
tout casser pour corriger les précédentes, non ? Ils pourraient créer une nouvelle version des classes qui font .get(Object) -> .get(K), mais il y a déjà eu des changement récent dans les collections, donc, je doute ...
le get(Object) a peut etre une raison, cela évite de faire des cast non
nécéssaires a mon avis.
Un exemple pour illustrer ça ?
Et je pense pas qu'ils changent ca, car cela
interdirait de compiler le code écrit en jdk 1.5 avec un jdk qui
modifierait ce comportement
C'est là tout l'intérêt des versions majeures : on a le droit de
tout casser pour corriger les précédentes, non ? Ils pourraient
créer une nouvelle version des classes qui font .get(Object) ->
.get(K), mais il y a déjà eu des changement récent dans les
collections, donc, je doute ...
le get(Object) a peut etre une raison, cela évite de faire des cast non nécéssaires a mon avis. Un exemple pour illustrer ça ?
Et je pense pas qu'ils changent ca, car cela interdirait de compiler le code écrit en jdk 1.5 avec un jdk qui modifierait ce comportement C'est là tout l'intérêt des versions majeures : on a le droit de
tout casser pour corriger les précédentes, non ? Ils pourraient créer une nouvelle version des classes qui font .get(Object) -> .get(K), mais il y a déjà eu des changement récent dans les collections, donc, je doute ...
Kupee
le get(Object) a peut etre une raison, cela évite de faire des cast non nécéssaires a mon avis. Un exemple pour illustrer ça ?
Et je pense pas qu'ils changent ca, car cela interdirait de compiler le code écrit en jdk 1.5 avec un jdk qui modifierait ce comportement C'est là tout l'intérêt des versions majeures : on a le droit de
tout casser pour corriger les précédentes, non ? Ils pourraient créer une nouvelle version des classes qui font .get(Object) -> .get(K), mais il y a déjà eu des changement récent dans les collections, donc, je doute ...
Ben non même les versions majeures doivent rester compatibles je crois en java. Cela dit je crois qu'il existe des exceptions. Certaines interfaces ont gagné des méthodes parfois et du coup ca compile plus parfois
le get(Object) a peut etre une raison, cela évite de faire des cast non
nécéssaires a mon avis.
Un exemple pour illustrer ça ?
Et je pense pas qu'ils changent ca, car cela
interdirait de compiler le code écrit en jdk 1.5 avec un jdk qui
modifierait ce comportement
C'est là tout l'intérêt des versions majeures : on a le droit de
tout casser pour corriger les précédentes, non ? Ils pourraient
créer une nouvelle version des classes qui font .get(Object) ->
.get(K), mais il y a déjà eu des changement récent dans les
collections, donc, je doute ...
Ben non même les versions majeures doivent rester compatibles je crois
en java. Cela dit je crois qu'il existe des exceptions. Certaines
interfaces ont gagné des méthodes parfois et du coup ca compile plus parfois
le get(Object) a peut etre une raison, cela évite de faire des cast non nécéssaires a mon avis. Un exemple pour illustrer ça ?
Et je pense pas qu'ils changent ca, car cela interdirait de compiler le code écrit en jdk 1.5 avec un jdk qui modifierait ce comportement C'est là tout l'intérêt des versions majeures : on a le droit de
tout casser pour corriger les précédentes, non ? Ils pourraient créer une nouvelle version des classes qui font .get(Object) -> .get(K), mais il y a déjà eu des changement récent dans les collections, donc, je doute ...
Ben non même les versions majeures doivent rester compatibles je crois en java. Cela dit je crois qu'il existe des exceptions. Certaines interfaces ont gagné des méthodes parfois et du coup ca compile plus parfois
fabrice-pas-despame.bacchella
On 20 Sep 2006 00:16:00 -0700, "gvauvert" wrote:
Pourra-t-elle être faite dans le cadre du JDK6 ? Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine béta ;-) Mouais, je pense que la libération sera une "conditionnelle", et que
la 6 sortira avant (pour bonne conduite).
Pour faire évoluer java, il y a déjà le JCP. Quand au code source, il est déjà dispo. Le débat porte seulement sur le modèle de licence.
On 20 Sep 2006 00:16:00 -0700, "gvauvert" <gvauvert@gmail.com> wrote:
Pourra-t-elle être faite dans le cadre du JDK6 ?
Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine
béta ;-)
Mouais, je pense que la libération sera une "conditionnelle", et que
la 6 sortira avant (pour bonne conduite).
Pour faire évoluer java, il y a déjà le JCP. Quand au code source, il
est déjà dispo. Le débat porte seulement sur le modèle de licence.
Pourra-t-elle être faite dans le cadre du JDK6 ? Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine béta ;-) Mouais, je pense que la libération sera une "conditionnelle", et que
la 6 sortira avant (pour bonne conduite).
Pour faire évoluer java, il y a déjà le JCP. Quand au code source, il est déjà dispo. Le débat porte seulement sur le modèle de licence.
TestMan
On 20 Sep 2006 00:16:00 -0700, "gvauvert" wrote:
Pourra-t-elle être faite dans le cadre du JDK6 ? Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine béta ;-) Mouais, je pense que la libération sera une "conditionnelle", et que
la 6 sortira avant (pour bonne conduite).
Pour faire évoluer java, il y a déjà le JCP. Quand au code source, il est déjà dispo. Le débat porte seulement sur le modèle de licence.
De plus pour des changements aussi mineurs une simple validation du groupe d'expert de la JSR devrait suffir ;-)
On 20 Sep 2006 00:16:00 -0700, "gvauvert" <gvauvert@gmail.com> wrote:
Pourra-t-elle être faite dans le cadre du JDK6 ?
Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine
béta ;-)
Mouais, je pense que la libération sera une "conditionnelle", et que
la 6 sortira avant (pour bonne conduite).
Pour faire évoluer java, il y a déjà le JCP. Quand au code source, il
est déjà dispo. Le débat porte seulement sur le modèle de licence.
De plus pour des changements aussi mineurs une simple validation du
groupe d'expert de la JSR devrait suffir ;-)
Pourra-t-elle être faite dans le cadre du JDK6 ? Tout dépend si Sun "libère" le code du Java SE RI avant la prochaine béta ;-) Mouais, je pense que la libération sera une "conditionnelle", et que
la 6 sortira avant (pour bonne conduite).
Pour faire évoluer java, il y a déjà le JCP. Quand au code source, il est déjà dispo. Le débat porte seulement sur le modèle de licence.
De plus pour des changements aussi mineurs une simple validation du groupe d'expert de la JSR devrait suffir ;-)
TestMan
le get(Object) a peut etre une raison, cela évite de faire des cast non nécéssaires a mon avis. Un exemple pour illustrer ça ?
Et je pense pas qu'ils changent ca, car cela interdirait de compiler le code écrit en jdk 1.5 avec un jdk qui modifierait ce comportement C'est là tout l'intérêt des versions majeures : on a le droit de
tout casser pour corriger les précédentes, non ? Ils pourraient créer une nouvelle version des classes qui font .get(Object) -> .get(K), mais il y a déjà eu des changement récent dans les collections, donc, je doute ...
Non, il n'a aucune raison fondée sauf le fait que celui qui a évalue le bug envoyé dans le bug parade ne devait debuté en généricité ;-)
De plus selon la sémantique du Map le comportement du get est erroné !
Si tu crée un Map<Number,Budule> c'est pour que le type de la clé soit "cohérent" (en clair une instance de Number) l'argument de l'evaluateur du bug est de dire qu'on doit pouvoir faire un .get(Slurb) est complétement innutile et ridicule, car on ne peut pas faire de .put(Slurb,Bidule) puis que la signature des put est : V put(K , V ) !
Ben non même les versions majeures doivent rester compatibles je crois en java. Cela dit je crois qu'il existe des exceptions. Certaines interfaces ont gagné des méthodes parfois et du coup ca compile plus parfois
On peut citer par exemple l'arrivée du collection framework qui a apporté en 1.2 une class List "homonyme" de celle présente dans l'AWT. L'impact a été de devoir modifier les fichiers source utilisant import java.awt.* et import java.util.* des sources en 1.1 ;-
Map<Number,Truc> map;
De devoir corriger en :
Map<? extends Number, Truc> map;
S'ils venlent toujours pouvoir faire un :
map.get(new Integer(0));
Ainsi, je ne suis pas sûr que la correction du bug impacte des masses de personnes ;-)
le get(Object) a peut etre une raison, cela évite de faire des cast non
nécéssaires a mon avis.
Un exemple pour illustrer ça ?
Et je pense pas qu'ils changent ca, car cela
interdirait de compiler le code écrit en jdk 1.5 avec un jdk qui
modifierait ce comportement
C'est là tout l'intérêt des versions majeures : on a le droit de
tout casser pour corriger les précédentes, non ? Ils pourraient
créer une nouvelle version des classes qui font .get(Object) ->
.get(K), mais il y a déjà eu des changement récent dans les
collections, donc, je doute ...
Non, il n'a aucune raison fondée sauf le fait que celui qui a évalue le
bug envoyé dans le bug parade ne devait debuté en généricité ;-)
De plus selon la sémantique du Map le comportement du get est erroné !
Si tu crée un Map<Number,Budule> c'est pour que le type de la clé soit
"cohérent" (en clair une instance de Number) l'argument de l'evaluateur
du bug est de dire qu'on doit pouvoir faire un .get(Slurb) est
complétement innutile et ridicule, car on ne peut pas faire de
.put(Slurb,Bidule) puis que la signature des put est : V put(K , V ) !
Ben non même les versions majeures doivent rester compatibles je crois
en java. Cela dit je crois qu'il existe des exceptions. Certaines
interfaces ont gagné des méthodes parfois et du coup ca compile plus
parfois
On peut citer par exemple l'arrivée du collection framework qui a
apporté en 1.2 une class List "homonyme" de celle présente dans l'AWT.
L'impact a été de devoir modifier les fichiers source utilisant import
java.awt.* et import java.util.* des sources en 1.1 ;-
Map<Number,Truc> map;
De devoir corriger en :
Map<? extends Number, Truc> map;
S'ils venlent toujours pouvoir faire un :
map.get(new Integer(0));
Ainsi, je ne suis pas sûr que la correction du bug impacte des masses de
personnes ;-)
le get(Object) a peut etre une raison, cela évite de faire des cast non nécéssaires a mon avis. Un exemple pour illustrer ça ?
Et je pense pas qu'ils changent ca, car cela interdirait de compiler le code écrit en jdk 1.5 avec un jdk qui modifierait ce comportement C'est là tout l'intérêt des versions majeures : on a le droit de
tout casser pour corriger les précédentes, non ? Ils pourraient créer une nouvelle version des classes qui font .get(Object) -> .get(K), mais il y a déjà eu des changement récent dans les collections, donc, je doute ...
Non, il n'a aucune raison fondée sauf le fait que celui qui a évalue le bug envoyé dans le bug parade ne devait debuté en généricité ;-)
De plus selon la sémantique du Map le comportement du get est erroné !
Si tu crée un Map<Number,Budule> c'est pour que le type de la clé soit "cohérent" (en clair une instance de Number) l'argument de l'evaluateur du bug est de dire qu'on doit pouvoir faire un .get(Slurb) est complétement innutile et ridicule, car on ne peut pas faire de .put(Slurb,Bidule) puis que la signature des put est : V put(K , V ) !
Ben non même les versions majeures doivent rester compatibles je crois en java. Cela dit je crois qu'il existe des exceptions. Certaines interfaces ont gagné des méthodes parfois et du coup ca compile plus parfois
On peut citer par exemple l'arrivée du collection framework qui a apporté en 1.2 une class List "homonyme" de celle présente dans l'AWT. L'impact a été de devoir modifier les fichiers source utilisant import java.awt.* et import java.util.* des sources en 1.1 ;-
Map<Number,Truc> map;
De devoir corriger en :
Map<? extends Number, Truc> map;
S'ils venlent toujours pouvoir faire un :
map.get(new Integer(0));
Ainsi, je ne suis pas sûr que la correction du bug impacte des masses de personnes ;-)
