Quand dois-Java génériques nécessitent <? s'étend T> au lieu de <T>, et est-il un inconvénient de commutation?

Donné l'exemple suivant (en utilisant JUnit avec Hamcrest les allumettes):

Map<String, Class<? extends Serializable>> expected = null;
Map<String, Class<java.util.Date>> result = null;
assertThat(result, is(expected));

Cela ne compile pas avec JUnit assertThat signature de la méthode de:

public static <T> void assertThat(T actual, Matcher<T> matcher)

Le compilateur message d'erreur est:

Error:Error:line (102)cannot find symbol method
assertThat(java.util.Map<java.lang.String,java.lang.Class<java.util.Date>>,
org.hamcrest.Matcher<java.util.Map<java.lang.String,java.lang.Class
    <? extends java.io.Serializable>>>)

Cependant, si je change le assertThat signature de la méthode d':

public static <T> void assertThat(T result, Matcher<? extends T> matcher)

Alors la compilation fonctionne.

Donc trois questions:

Exactement pourquoi ne pas la version actuelle de la compilation? Bien que j'ai vaguement comprendre la covariance des questions ici, je ne peux pas l'expliquer si je devais le faire.
Est-il un inconvénient dans l'évolution de la assertThat méthode pour Matcher<? extends T>? Il existe d'autres cas de rupture si vous l'avez fait?
Il y a tout point à la genericizing de la assertThat méthode dans JUnit? Le Matcher classe ne semble pas à l'exiger, depuis JUnit appelle les matches de la méthode, qui n'est pas typé avec un médicament générique, et ressemble à une tentative de forcer un type de la sécurité qui permet de ne pas faire n'importe quoi, comme le Matcher sera tout simplement pas en fait de match, et que le test échoue, peu importe. Pas d'activités dangereuses impliquées (ou ce qu'il paraît).

Pour référence, voici la JUnit mise en œuvre de assertThat:

public static <T> void assertThat(T actual, Matcher<T> matcher) {
    assertThat("", actual, matcher);
}

public static <T> void assertThat(String reason, T actual, Matcher<T> matcher) {
    if (!matcher.matches(actual)) {
        Description description = new StringDescription();
        description.appendText(reason);
        description.appendText("\nExpected: ");
        matcher.describeTo(description);
        description
            .appendText("\n     got: ")
            .appendValue(actual)
            .appendText("\n");

        throw new java.lang.AssertionError(description.toString());
    }
}

ce lien est très utile (génériques, d'héritage et de sous-type): docs.oracle.com/javase/tutorial/java/generics/inheritance.html

InformationsquelleAutor Yishai | 2009-05-22

128

Première - j'ai à vous diriger vers http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html -- elle fait un travail incroyable.

L'idée de base est que vous utilisez
```
<T extends SomeClass>
```
lorsque le paramètre peut être SomeClass ou de tout sous-type de il.

Dans votre exemple,
```
Map<String, Class<? extends Serializable>> expected = null;
Map<String, Class<java.util.Date>> result = null;
assertThat(result, is(expected));
```
Vous êtes en train de dire que expected peut contenir des objets de la Classe, qui représentent toute classe qui implémente Serializable. Votre résultat de carte dit qu'il ne peut contenir Date les objets de la classe.

Quand vous passez par conséquent, la configuration de T exactement Map de String à Date les objets de la classe, qui ne correspond pas Map de String pour tout ce qui est Serializable.

Une chose à vérifier -- êtes-vous sûr que vous voulez Class<Date> et pas Date? Une carte de String à Class<Date> ne sonne pas très utile en général (tout ce qu'il peut contenir est Date.class comme des valeurs plutôt que des instances de Date)

Comme pour genericizing assertThat, l'idée est que la méthode peut s'assurer qu'un Matcher qui s'adapte le type de résultat est passée.
- Dans ce cas, oui, je veux une carte de classes. L'exemple que j'ai donné est contraint d'utiliser les classes du JDK plutôt que mes classes personnalisées, mais dans ce cas, la classe est instanciée par la réflexion et utilisés en fonction de la clé. (Une application distribuée où le client n'a pas les classes de serveur disponible, juste la touche de classe à utiliser pour le serveur de travailler sur le côté).
- Je suppose que lorsque mon cerveau est bloqué est pourquoi une Carte contenant des classes de type Date n'est pas seulement parfaitement dans un type de Cartes contenant des classes de type Serializable. Assurez-vous que les classes de type Serializable pourraient être les autres classes, mais il comprend bien sûr le type Date.
- Sur le assertThat assurant la distribution est effectuée pour vous, le matcher.correspond à() la méthode n'a pas fait attention, donc, depuis le T n'est jamais utilisé, pourquoi impliquer? (la méthode de type de retour est void)
- Ahhh - c'est ce que je reçois pour ne pas lire la def de la assertThat assez proche. On dirait qu'il est seulement pour assurer un montage Comparateur de est passé dans...
InformationsquelleAutor Scott Stanchfield
24

Merci à tous ceux qui ont répondu à la question, il a vraiment aidé à clarifier les choses pour moi. À la fin de Scott Stanchfield de réponse obtenu le plus proche de la façon dont j'ai fini par le comprendre, mais puisque je n'ai pas le comprendre quand il a commencé à l'écrire, je suis en train de reformuler le problème, dans l'espoir que quelqu'un d'autre en profitera.

Je vais reformuler la question en termes de Liste, car il n'a qu'un seul paramètre générique et qui sera plus facile à comprendre.

Le but de la paramétrée de classe (comme la Liste<Date> ou Carte<K, V> comme dans l'exemple) est à force un triste et que le compilateur garantir que c'est sans danger (pas des exceptions d'exécution).

Prenons le cas de la Liste. L'essence de ma question est pourquoi une méthode qui prend un type T et une Liste de ne pas accepter une Liste de quelque chose de plus bas dans la chaîne de l'héritage que T. Considérons cet exemple artificiel:
```
List<java.util.Date> dateList = new ArrayList<java.util.Date>();
Serializable s = new String();
addGeneric(s, dateList);

....
private <T> void addGeneric(T element, List<T> list) {
    list.add(element);
}
```
Ce ne sera pas compiler, parce que le paramètre de liste est une liste de dates, pas une liste de chaînes de caractères. Les génériques ne serait pas très utile si ce n'compiler.

La même chose s'applique à une Carte<String, Class<? extends Serializable>> Ce n'est pas la même chose qu'une Carte<String, Class<java.util.Date>>. Ils ne sont pas covariants, donc si je voulais prendre une valeur à partir de la carte contenant la date de classes et de le mettre dans la carte contenant serializable éléments, c'est bien, mais une signature de méthode qui dit:
```
private <T> void genericAdd(T value, List<T> list)
```
Veut être en mesure de faire les deux:
```
T x = list.get(0);
```
et
```
list.add(value);
```
Dans ce cas, même si la junit méthode ne fait pas de soins au sujet de ces choses, la signature de la méthode nécessite la covariance, qui elle n'est pas arriver, donc il ne compile pas.

Sur la deuxième question,
```
Matcher<? extends T>
```
Aurait l'inconvénient de vraiment accepter quoi que ce soit, lorsque T est un Objet, qui n'est pas l'Api intention. L'intention est de manière statique s'assurer que le matcher correspond à l'objet réel, et il n'y a aucun moyen de les exclure de l'Objet à partir de ce calcul.

La réponse à la troisième question, c'est que rien ne serait perdu, en termes de fonctionnalité désactivée (il n'y aurait pas dangereux typecasting au sein de la JUnit API si cette méthode n'a pas été généricisés), mais ils sont en train d'essayer d'accomplir quelque chose d'autre, statique s'assurer que les deux paramètres sont susceptibles de match.

EDIT (après plus de la contemplation et de l'expérience):

L'un des plus gros problèmes avec le assertThat signature de la méthode est de tentatives d'assimiler une variable T avec un paramètre générique de T. cela ne fonctionne pas, parce qu'ils ne sont pas covariants. Ainsi, par exemple, vous pouvez avoir un T qui est un List<String> mais puis de passer un match que le compilateur travaille à Matcher<ArrayList<T>>. Maintenant, si ce n'était pas un paramètre de type, ce serait bien, parce que la Liste et liste de tableaux sont covariants, mais puisque les Génériques, aussi loin que le compilateur est concerné besoin ArrayList, il ne peut pas tolérer une Liste pour des raisons que j'espère clair.
- Je ne comprends toujours pas pourquoi je ne peux pas sortie si. Pourquoi je ne peux pas tourner à une liste de dates dans une liste de sérialisable?
- parce que les références qui pense que c'est une liste de Dates sera exécuté dans les erreurs de conversion quand ils les trouvent, de Chaînes ou toute autre serializables.
- Je vois, mais si j'ai un peu eu débarrasser de l'ancienne référence, comme si je retourne le List<Date> à partir d'une méthode de type List<Object>? Qui devrait être à l'abri droit, même si c'est pas autorisé par java.
InformationsquelleAutor Yishai
14

Ça se résume à:
```
Class<? extends Serializable> c1 = null;
Class<java.util.Date> d1 = null;
c1 = d1; //compiles
d1 = c1; //wont compile - would require cast to Date
```
Vous pouvez voir la référence de Classe c1 pourrait contenir une Longue instance (depuis l'objet sous-jacent à un moment donné pourrait avoir été List<Long>), mais, évidemment, ne peut pas être lancé à une Date car il n'y a aucune garantie que "l'inconnu" de classe a Date. Il n'est pas typsesafe, de sorte que le compilateur ne l'autorise pas.

Cependant, si nous introduisons un autre objet, disons Liste (dans votre exemple, cet objet est Matcher), alors celui-ci devient vrai:
```
List<Class<? extends Serializable>> l1 = null;
List<Class<java.util.Date>> l2 = null;
l1 = l2; //wont compile
l2 = l1; //wont compile
```
...Cependant, si le type de la Liste devient ? s'étend T au lieu de T....
```
List<? extends Class<? extends Serializable>> l1 = null;
List<? extends Class<java.util.Date>> l2 = null;
l1 = l2; //compiles
l2 = l1; //won't compile
```
Je pense qu'en changeant Matcher<T> to Matcher<? extends T>, vous êtes essentiellement l'introduction du scénario similaire à l'attribution l1 = l2;

C'est encore très confus d'avoir des caractères génériques imbriqués, mais j'espère que ça a du sens pour expliquer pourquoi il est utile de comprendre les génériques en regardant comment vous pouvez attribuer des références génériques les uns aux autres. C'est aussi plus de confusion puisque le compilateur est d'inférer le type de T lorsque vous faites l'appel de la fonction (vous n'êtes pas explicitement dire qu'il était T).

InformationsquelleAutor GreenieMeanie
8

La raison de votre origine code ne compile pas, c'est que <? extends Serializable> ne pas veux dire, "toute classe qui étend la classe Sérialisable," mais ", des inconnus, mais de classe qui étend la classe Sérialisable."

Par exemple, dans le code écrit, il est parfaitement valable pour attribuer new TreeMap<String, Long.class>()> à expected. Si le compilateur a permis le code à compiler, le assertThat() ne serait sans doute pause, car il pourrait s'attendre à Date objets au lieu de les Long les objets qu'il trouve dans la carte.
- Je ne suis pas tout à fait la suite - quand vous dites "ne veut pas dire ... mais ...": quelle est la différence? (comme, ce serait un exemple de "connu mais non spécifiques" de la classe, qui correspond à la définition ancienne, mais pas le dernier?)
- Oui, c'est un peu maladroit; vous ne savez pas comment l'exprimer mieux... est-il plus logique de dire, "'?' est un type qui est inconnu, pas un type qui correspond à quelque chose?"
- Ce qui peut aider à expliquer c'est que, pour que "toute la classe qui extends Serializable" vous pouvez simplement utiliser <Serializable>
InformationsquelleAutor erickson
7

Une façon pour moi de comprendre les caractères génériques, c'est de penser que le générique n'est pas de spécifier le type de la possible des objets que, compte tenu de référence générique peut "avoir", mais le type de d'autres références génériques qu'il est compatible avec (ce qui peut sembler déroutant...) en tant Que telle, la première réponse est très trompeur en ce qu'il est libellé.

En d'autres termes, List<? extends Serializable> signifie que vous pouvez attribuer que la référence à d'autres Listes dont le type est un certain type inconnu qui est ou une sous-classe Sérialisable. NE PAS penser en termes d'UNE LISTE UNIQUE d'être en mesure de tenir les sous-classes de Serializable (parce que c'est incorrect de la sémantique et conduit à une incompréhension de Génériques).
- Qui aide certainement, mais le "peut sembler déroutant" est une sorte d'remplacé par une "confusion des sons." Par la suite, alors pourquoi, selon cette explication, la méthode avec Matcher<? extends T> compiler?
- si nous définissons comme une Liste<Serializable>, il fait la même chose non? Je parle de votre 2ème par. c'est à dire le polymorphisme de le manipuler?
InformationsquelleAutor GreenieMeanie
3

Je sais que c'est une vieille question, mais je veux donner un exemple qui, je pense, explique délimitée jokers assez bien. java.util.Collections propose cette méthode:
```
public static <T> void sort(List<T> list, Comparator<? super T> c) {
    list.sort(c);
}
```
Si nous avons une Liste de T, la Liste peut, bien sûr, contenir des instances de types qui s'étendent T. Si la Liste contient des Animaux, la Liste peut contenir à la fois les Chiens et les Chats (Animaux). Les chiens ont une propriété "woofVolume" et les Chats ont une propriété "meowVolume." Alors que nous le voudrions pour trier sur la base de ces propriétés particulières pour les sous-classes de T, comment pouvons-nous attendre de cette méthode pour le faire? Une limitation de Comparateur est qu'il peut seulement comparer deux choses d'un seul type (T). Donc, nécessitant simplement un Comparator<T> rendrait cette méthode utilisable. Mais, le créateur de cette méthode a reconnu que si quelque chose est un T, il est aussi une instance de la super-classes de T. Par conséquent, il nous permet d'utiliser un Comparateur de T ou de tout super-classe de T, c'est à dire ? super T.

InformationsquelleAutor Lucas Ross
1

que si vous utilisez
```
Map<String, ? extends Class<? extends Serializable>> expected = null;
```
- Oui, c'est le genre de ce que ma réponse ci-dessus a été conduite.
- Non, cela n'aide pas la situation, au moins la façon dont je l'ai essayé.
InformationsquelleAutor newacct

Vous devez vous connecter pour publier un commentaire.