IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Affichage des résultats du sondage: Etes vous pour ou contre cette proposition ?

Votants
202. Vous ne pouvez pas participer à ce sondage.
  • Pour

    161 79,70%
  • Contre

    41 20,30%
Langage Java Discussion :

JDK 7: Proposition 2 : Créer facilement des Collections génériques vides [Débat]


Sujet :

Langage Java

  1. #1
    Expert éminent sénior


    Profil pro
    Inscrit en
    Mai 2003
    Messages
    3 240
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2003
    Messages : 3 240
    Points : 11 101
    Points
    11 101
    Par défaut JDK 7: Proposition 2 : Créer facilement des Collections génériques vides
    Aujourd'hui :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    public <E> Set<E> emptySet() { … }
    void timeWaitsFor(Set<Man> people) { … }
    
    // * Won't compile!
    timeWaitsFor(Collections.emptySet());
    
    // OK
    timeWaitsFor(Collections.<Man>emptySet());
    Demain :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    public <E> Set<E> emptySet() { … }
    void timeWaitsFor(Set<Man> people) { … }
    
    // OK
    timeWaitsFor(Collections.emptySet());
    Vincent Brabant

    Ne pas me contacter par MP ni par mail pour des questions techniques. Ma liste d'amis restera vide.

    Cours et tutoriels pour apprendre Java , FAQ Java, et Forum Java

  2. #2
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Oui : a noter que cela ne concerne pas seulement les Collections génériques mais n'importe quelles méthodes paramétrées

    a++

  3. #3
    Membre éprouvé
    Avatar de n!co
    Profil pro
    Inscrit en
    Février 2004
    Messages
    831
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France

    Informations forums :
    Inscription : Février 2004
    Messages : 831
    Points : 936
    Points
    936
    Par défaut
    J'ai voté OK, mais avec quelques intérrogations :
    1. Collections.emptySet() retourne une liste immuable donc pas de soucis en cas d'essaye d'ajout d'un element quelconque à cette liste ?
    2. Le "foreach" ne risque pas de poser problème ?
    Netbeans account : nico@share.java.net
    Merci de ne pas poser de questions techniques par MP

  4. #4
    Membre actif
    Avatar de bobuse
    Profil pro
    Inscrit en
    Janvier 2005
    Messages
    232
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 232
    Points : 278
    Points
    278
    Par défaut
    Je trouve l'exemple mal formulé en fait. Je pense avoir compris que la fonction emptySet collée dans l'exemple du code provient en fait de Collections.

    Bref, je n'en ai jamais eu l'utilité, donc je ne me rend pas compte de la gène occasionné. Donc je ne vote pas

  5. #5
    Modérateur
    Avatar de OButterlin
    Homme Profil pro
    Inscrit en
    Novembre 2006
    Messages
    7 310
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations forums :
    Inscription : Novembre 2006
    Messages : 7 310
    Points : 9 522
    Points
    9 522
    Billets dans le blog
    1
    Par défaut
    Bof, on pourrait utiliser quelque chose dans le genre
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    timeWaitsFor(new ArrayList<>());
    si le point 1 est OK
    N'oubliez pas de consulter les FAQ Java et les cours et tutoriels Java

  6. #6
    Membre éclairé Avatar de bassim
    Homme Profil pro
    Ingénieur Réseaux
    Inscrit en
    Février 2005
    Messages
    666
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 38
    Localisation : France, Hauts de Seine (Île de France)

    Informations professionnelles :
    Activité : Ingénieur Réseaux
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Février 2005
    Messages : 666
    Points : 695
    Points
    695
    Par défaut
    J'ai pas voté parceque je ne vois pas vraiment l'utilité de ça !

    si quelqu'un a un exemple plus concret
    Where is my mind

  7. #7
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par bobuse Voir le message
    Bref, je n'en ai jamais eu l'utilité, donc je ne me rend pas compte de la gène occasionné. Donc je ne vote pas
    En fait le problème ne vient pas directement des Collections mais des Generics sur les méthodes. Mais ce problème ne se pose que dans très peu de cas très spécifique.

    Attention je parle bien des méthodes generics et non pas des classes generics, c'est à dire que le <T> est situé sur la méthode et non pas sur la classe. Par exemple si on prend la méthode Collections.sort() déclaré comme ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    public static <T extends Comparable<? super T>> void sort(List<T> list) {
    En fait lorsque on l'utilise on devrait toujours spécifié le type paramétré comme ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    	List<String> list = ...
     
    	Collections.<String>sort(list);
    Heureusement le compilateur arrive à détecter le paramétrage par lui même et on n'est pas obligé de l'indiquer et continuer à écrire simplement :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Collections.sort(list);
    Comme list est de type List<String>, le compilateur arrive à déterminer que <T> correspond à String...


    En fait on n'est obligé d'indiquer le paramétrage qu'en cas d'ambigüité du compilateur, mais en règle général c'est assez rare...



    Le problème avec emptySet() (et les autres méthodes du même type), c'est que le compilateur ne peut se baser que sur le type de retour et qu'il est assez limité.

    emptySet() est déclaré de la manière suivante :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    public static final <T> Set<T> emptySet() {
    Lorsque tu fais ceci il n'y a aucun problème :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    Set<String> set = Collections.emptySet();
    Le compilateur arrive à déterminer que <T> vaut String
    selon le type de la variable qui va recevoir la valeur de retour.


    Par contre lorsque tu utilises une méthode, cela ne marche plus :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    public void method(Set<String> set) {
     ...
    }
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    method( Collections.emptySet() ); // BAD
    Ne marche pas car la valeur de retour n'est pas mise dans une variable, et que le compilateur ne peut donc pas la déterminer par ce moyen là.

    Pourtant dans ce cas le compilateur pourrait très bien utiliser le type du paramètre de la méthode pour déterminer le paramétrage à utiliser...


    Cette proposition consiste en fait à simplement faire en sorte que le compilateur utilise également le type des paramètres qui reçoivent le retour d'une méthode...


    C'est vraiment un cas très particulier assez anedoctique mais je pense que cela devrait être pris en compte...



    @ n!co
    1. La modficiation de emptySet() ou autre renvoi une exception
    2. foreach ne pose aucun problème (on n'y rentre tout simplement pas).

    a++

  8. #8
    Membre actif
    Avatar de bobuse
    Profil pro
    Inscrit en
    Janvier 2005
    Messages
    232
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Janvier 2005
    Messages : 232
    Points : 278
    Points
    278
    Par défaut
    Merci adibuga pour ces éclaircissements. Du coup, je vote pour, car ça ne bouleverse rien de manière inquiétante, et que ça apporte un petit plus. J'y repenserai si je tombe sur ce cas rare

  9. #9
    Membre émérite
    Avatar de xavlours
    Inscrit en
    Février 2004
    Messages
    1 832
    Détails du profil
    Informations forums :
    Inscription : Février 2004
    Messages : 1 832
    Points : 2 410
    Points
    2 410
    Par défaut
    J'ai voté pour, parce que l'explication d'adiguba m'a fait mal à la tête et que je ne veux plus jamais avoir à me poser cette question
    "Le bon ni le mauvais ne me feraient de peine si si si je savais que j'en aurais l'étrenne." B.V.
    Non au langage SMS ! Je ne répondrai pas aux questions techniques par MP.
    Eclipse : News, FAQ, Cours, Livres, Blogs.Et moi.

  10. #10
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Citation Envoyé par xavlours Voir le message
    parce que l'explication d'adiguba m'a fait mal à la tête
    désolé

    a++

  11. #11
    Membre expérimenté
    Avatar de Patriarch24
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Septembre 2003
    Messages
    1 047
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 40
    Localisation : France

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : Industrie

    Informations forums :
    Inscription : Septembre 2003
    Messages : 1 047
    Points : 1 640
    Points
    1 640
    Par défaut
    J'ai voté pour, parce que l'explication d'adiguba m'a fait mal à la tête et que je ne veux plus jamais avoir à me poser cette question
    Pareil.
    En premier lieu, utilisez un moteur de recherche.
    En second lieu, postez sur le forum adéquat !

  12. #12
    Nouveau Candidat au Club

    Profil pro
    Inscrit en
    Juin 2003
    Messages
    452
    Détails du profil
    Informations personnelles :
    Âge : 48
    Localisation : Afghanistan

    Informations forums :
    Inscription : Juin 2003
    Messages : 452
    Points : 0
    Points
    0
    Billets dans le blog
    1
    Par défaut
    C'est du sucre syntaxique,il y a des évolutions qui sont plus importantes comme la facilitation de l'écriture des classes anonymes ou l'ajout des closures.

  13. #13
    Membre régulier
    Profil pro
    Président
    Inscrit en
    Novembre 2006
    Messages
    100
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Président

    Informations forums :
    Inscription : Novembre 2006
    Messages : 100
    Points : 102
    Points
    102
    Par défaut
    ma tête fais mâle de cette exemple.

  14. #14
    Invité
    Invité(e)
    Par défaut
    Je ne vois pas du tout l'intérêt, le type générique dépend de l'usage que l'on en fait?

    Encore une fois, ça n'encourage pas l'utilisation d'interfaces dans les déclarations génériques, et le code devient moins clair.

    Inutile, à mon avis, donc.

  15. #15
    Expert éminent sénior
    Avatar de adiGuba
    Homme Profil pro
    Développeur Java/Web
    Inscrit en
    Avril 2002
    Messages
    13 938
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Java/Web
    Secteur : Transports

    Informations forums :
    Inscription : Avril 2002
    Messages : 13 938
    Points : 23 190
    Points
    23 190
    Billets dans le blog
    1
    Par défaut
    Heu... J'ai l'impression que mon explication a embrouillé tout le monde... je vais essayer de faire plus clair.




    Prenons une méthode paramétrée, par exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    public class Tools {
    	public static <T> List<T> createList() {
    		return new ArrayList<T>();
    	}
    }
    Cette méthode permet de créer une ArrayList paramétrée, par exemple :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    	List<Integer> integerList = Tools.createList();
    	List<String> stringList = Tools.createList();
    C'est ce qu'il est déjà possible de faire avec les Generics depuis Java 5. Mais comme createList() est une méthode paramétrée on devrait normalement spécifier le type paramétré à utiliser (le <T>), comme ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    	List<Integer> integerList = Tools.<Integer>createList();
    	List<String> stringList = Tools.<String>createList();
    Je suis sûr qu'une grande majorité ignore complètement l'existence de cette syntaxe (qui n'est d'ailleurs pas très agréable à l'oeil).

    En effet dans la plupart des cas elle est inutile puisque le compilateur arrive à détecter implicitement le type paramétré à utiliser :
    • Soit en regardant le type des paramètres de la méthodes (lorsqu'ils sont paramétrés).
    • Soit en regardant le type de la référence qui recevra la valeur de retour comme c'est le cas ici : createList() renvoi un List<T> qui est placé dans un List<Integer>, donc <T> est <Integer>.





    Seulement ce dernier cas est un peu limite car il ne vérifie pas la concordance des types si le retour est passé à une méthode, par exemple si j'ai une méthode comme ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    	public void setList(List<String> list) {
    		// ...
    	}
    On ne peux pas faire ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    setList( Tools.createList() ); // Ne compile PAS
    On est obligé de spécifier le type :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    setList( Tools.<String>createList() );
    Ceci tout simplement parce que le compilateur ne vas pas vérifier le type du paramètre de la méthode setList(). Il pourrait très bien le faire comme il le fait si on affecte le retour à un référence... mais non !


    Pour moi il ne s'agit pas vraiment d'une nouvelle proposition mais plutôt d'un oubli lors des spécifications des Generics... bref une correction de bug !




    a++

  16. #16
    Membre régulier
    Profil pro
    Président
    Inscrit en
    Novembre 2006
    Messages
    100
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : France, Yvelines (Île de France)

    Informations professionnelles :
    Activité : Président

    Informations forums :
    Inscription : Novembre 2006
    Messages : 100
    Points : 102
    Points
    102
    Par défaut
    merci adiGua de cette explication

  17. #17
    Rédacteur
    Avatar de pseudocode
    Homme Profil pro
    Architecte système
    Inscrit en
    Décembre 2006
    Messages
    10 062
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 51
    Localisation : France, Hérault (Languedoc Roussillon)

    Informations professionnelles :
    Activité : Architecte système
    Secteur : Industrie

    Informations forums :
    Inscription : Décembre 2006
    Messages : 10 062
    Points : 16 081
    Points
    16 081
    Par défaut
    J'ai voté pour. D'ailleurs je pensais que cette fonctionnalité etait déja implémentée depuis java 5.

    Comme dit adiGuba, ca ressemble plus a un "oubli" qu'a une évolution.
    ALGORITHME (n.m.): Méthode complexe de résolution d'un problème simple.

  18. #18
    Invité
    Invité(e)
    Par défaut
    Citation Envoyé par adiGuba Voir le message
    Heu... J'ai l'impression que mon explication a embrouillé tout le monde... je vais essayer de faire plus clair.
    [...]
    On ne peux pas faire ceci :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    setList( Tools.createList() ); // Ne compile PAS
    On est obligé de spécifier le type :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    setList( Tools.<String>createList() );
    Merci, c'est en effet très clair. Mais je ne vois pas ce qui est si gênant, car cela permet au développeur de savoir explicitement quel type transite.

    D'autant que si on utilise les génériques, on pourrait tout aussi bien avoir la méthode
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    public void setList(List<String> list) {
    		// ...
    	}
    générique également :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    public void setList(List<T> list) {
    		// ...
    	}
    Par ailleurs, si on utilise des types avec héritage, ou des types implémentant des interfaces, il faut bien que l'on spécifie explicitement le type, non?
    Nos 2 types implémentants Vehicule:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    Class Voiture implements Vehicule{[...]}
    Class Charette implements Vehicule{[...]}
    Notre méthode de réception qui ne connait pas l'implémentation du véhicule:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    public void setVehicule(<Vehicule> v) {}
    Une classe SingletonFactory qui nous retourne une instance unique de la classe spécifiée :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    public <T> getInstance() {[...]}
    et l'utilisation:
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
     
    setVehicule( SingletonFactory.<Charette>getInstance() );
    Je ne pratique pas depuis longtemps le Java5 et les génériques, donc veuillez m'excuser les erreurs de syntaxe, je pense que ça ne change pas grand chose à la logique.

    J'attends vos réactions et corrections syntaxiques si nécessaire.

  19. #19
    Membre émérite
    Avatar de xavlours
    Inscrit en
    Février 2004
    Messages
    1 832
    Détails du profil
    Informations forums :
    Inscription : Février 2004
    Messages : 1 832
    Points : 2 410
    Points
    2 410
    Par défaut
    Dans ton cas, il serait de toutes façons nécessaire de garder la précision du type, puisque la méthode getInstance peut retourner n'importe quel type. Par contre, si tu précises :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    public <T extends Vehicule> T getInstance() {...}
    Alors le typage explicite de la méthode getInstance est inutile lors de l'appel de setVehicule.
    "Le bon ni le mauvais ne me feraient de peine si si si je savais que j'en aurais l'étrenne." B.V.
    Non au langage SMS ! Je ne répondrai pas aux questions techniques par MP.
    Eclipse : News, FAQ, Cours, Livres, Blogs.Et moi.

  20. #20
    Membre actif
    Profil pro
    Étudiant
    Inscrit en
    Juillet 2004
    Messages
    230
    Détails du profil
    Informations personnelles :
    Âge : 34
    Localisation : Canada

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Juillet 2004
    Messages : 230
    Points : 250
    Points
    250
    Par défaut
    mouais bof je prefere que ca reste encore un peu verbeux .... c'est juste un petit plus

Discussions similaires

  1. JDK 7: Proposition 12 : déclaration des propriétés
    Par vbrabant dans le forum Langage
    Réponses: 127
    Dernier message: 16/10/2008, 20h13
  2. Réponses: 6
    Dernier message: 14/03/2008, 12h54
  3. Réponses: 6
    Dernier message: 22/05/2006, 21h12
  4. Réponses: 1
    Dernier message: 03/10/2005, 15h46
  5. Réponses: 4
    Dernier message: 21/09/2004, 22h25

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo