Méthodes génériques Java dans les classes génériques

avec des génériques Java, si vous utilisez la forme brute d'une classe générique, alors tous génériques sur la classe, même des méthodes génériques sans rapport telles que vos méthodes makeSingletonList et doSomething , deviennent crus. La raison pour laquelle je comprends qu'il est de fournir rétrocompatibilité avec le code Java écrit pré-génériques.

S'il n'y a pas d'utilisation pour votre paramètre de type générique T , alors il suffit de le supprimer de MyGenericClass , en laissant vos méthodes générique avec K . Sinon, vous devrez vivre avec le fait que le paramètre de type de classe T doit être donné à votre classe pour utiliser des génériques sur quoi que ce soit d'autre dans la classe.

j'ai trouvé une raison pour rejeter complètement les génériques (mais ce n'est pas tout à fait bon). La raison est: les génériques peuvent être délimités. Considérons cette classe:

public static class MyGenericClass<T> {
    public <K extends T> K doSomething(K k){
        return k;
    }

    public <K> List<K> makeSingletonList(K k){
        return Collections.singletonList(k);
    }
}

le compilateur doit rejeter les génériques dans doSomething , lorsque vous utilisez la classe sans génériques. Et je pense que tous les génériques sont rejetés pour être cohérent avec ce comportement.

makeSingletonList compile parce que Java n'a décoché un cast de List à List<K> (mais compilateur affiche d'avertissement).

cela ne répond pas à la question fondamentale, mais bien à celle de savoir pourquoi makeSingletonList(...) compile alors que doSomething(...) ne compile pas:

Dans un non de la mise en œuvre de MyGenericClass :

MyGenericClass untyped = new MyGenericClass();
List<String> list = untyped.makeSingletonList("String");

... est l'équivalent de:

MyGenericClass untyped = new MyGenericClass();
List list = untyped.makeSingletonList("String");
List<String> typedList = list;

cela compilera (avec plusieurs avertissements), mais est alors ouvert aux erreurs d'exécution.

en effet, c'est aussi analogue à:

MyGenericClass untyped = new MyGenericClass();
List<Integer> list = untyped.makeSingletonList("String"); // this compiles!!!
Integer a = list.get(0);

...qui se compile mais lancera un runtime ClassCastException quand vous essayez d'obtenir la valeur String et le lancer dans un Integer .

la raison en est la rétrocompatibilité avec le code pre-generics. Le code pre-generics n'utilisait pas d'arguments génériques, mais plutôt ce qui semble aujourd'hui être un type brut. Le code pré-génériques utiliserait Object au lieu de références utilisant le type générique, et les types crus utiliseraient le type Object pour tous les arguments génériques, de sorte que le code était en effet rétro-compatible.

par exemple, considérez ce code:

List list = new ArrayList();

il s'agit d'un code pré-générique, et une fois que des génériques ont été introduits, cela a été interprété comme un type générique brut équivalent à:

List<?> list = new ArrayList<>();

parce que le ? n'a pas de mot clé extends ou super après lui, il est transformé en ceci:

List<Object> list = new ArrayList<>();

la version de List qui a été utilisée avant génériques utilisé un Object pour se référer à un élément de liste, et cette version utilise également un Object pour se référer à un list element, donc la rétrocompatibilité est conservée.

de mon commentaire sur MAnyKeys réponse:

je pense que l'erasure de type complet a du sens combiné avec la compatibilité mentionnée à l'envers. Lorsque l'objet est créé sans argument de type générique, il peut l'être (ou devrait l'être?) supposait que l'usage de l'objet se déroulait en code non générique.

Considérer cet héritage de code:

public class MyGenericClass {
    public Object doSomething(Object k){
        return k;
    }
}

appelé comme ceci:

MyGenericClass foo = new MyGenricClass();
NotKType notKType = foo.doSomething(new NotKType());

maintenant la classe et sa méthode est rendue Générique:

public class MyGenericClass<T> {
    public <K extends KType> K doSomething(K k){
        return k;
    }
}

maintenant le code d'appelant ci-dessus ne compilerait plus comme NotKType n'est pas un suptype de KType . Pour éviter cela, les types génériques sont remplacés par Object . Bien qu'il y ait des cas où cela ne ferait aucune différence (comme votre exemple), il est au moins très complexe pour le compilateur d'analyser quand. Peut-être même impossible.

je sais que ce szenario semble un peu construit mais je suis sûr que ça arrive de temps en temps.