covariance entre génériques

Version imprimable

Bonjour,

Je ne comprends pas pourquoi le compilateur Java n'assure pas la conversion suivante.

En déclarant format() avec <K,V> (ligne commentée), je comprends que l'information générique sur K et V ne soit pas disponible dans TextOutputFormat.class.
Par contre, avec la déclaration Class<? extends InputFormat<?,?>> (ligne non commentée), tout se passe comme si TextOutputFormat et TextOutputFormat<?,?> n'étaient pas covariants.

Pourriez-vous m'expliquer ?
Merci d'avance.
Code:

1 2 3 4 A<Text,NullWritable> a = ...; a.format(TextOutputFormat.class); // PROBLEME : method is not applicable a.format((Class<? extends InputFormat<Text,NullWritable>>) TextOutputFormat.class); // ok
Code:

1 2 3 4 5 6 Interface A<K,V> { /** A setter for attribute format */ // public void format(Class<? extends InputFormat<K,V>> format); public void format(Class<? extends InputFormat<?,?>> format); }
Code:

1 2 3 4 5 java.lang.Object extended by org.apache.hadoop.mapreduce.OutputFormat<K,V> extended by org.apache.hadoop.mapreduce.lib.output.FileOutputFormat<K,V> extended by org.apache.hadoop.mapreduce.lib.output.TextOutputFormat<K,V>

11/10/2016, 19h05
adiGuba

Salut,

Je n'arrive pas à reproduire ton problème.
Quelle est ta version de Java ?
Comment est déclaré la classe TextOutputFormat ?

a++

Merci adiguba,

Java 1..8.0_102

Ci dessous un exemple simplifié
A <=> Interface A<K,V>
B <=> OutputFormat<K,V>
C <=> TextOutputFormat<K,V>

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
 
public class PipoTest {
    public static class B<K,V> {}
    public static class C<K,V> extends B<K,V> {}
    public static class D extends B<String,String> {}
 
    public static class A<K,V> {
        public void foo(Class<? extends B<?,?>> arg) {}
    }
    public static void main(String[] clargs) {
        A<String,String> a = new A<>();
        a.foo(C.class);
        // The method foo(Class<? extends PipoTest.B<?,?>>) in the type PipoTest.A<String,String> is not applicable for the arguments (Class<PipoTest.C>)
 
        a.foo( (Class<? extends C<String,String>>) C.class); // valid
        a.foo(D.class); // valid
    }
 
}

11/10/2016, 19h36
shaiHulud
En fait, même ceci ne marche pas :
Code:

1 2 a.foo(B.class);
11/10/2016, 20h06
adiGuba
Ok je pensais que TextOutputFormat était défini avec un type précis (comme "D" dans ton exemple).

Même ce code n'est pas valide :

Code:

a.foo( (Class<? extends C<String,String>>) C.class); // valid

Je suppose que tu compiles avec eclipse (qui ne signale qu'un warning), mais javac sort directement une erreur : incompatible types: Class<C> cannot be converted to Class<? extends C<String,String>>

Le "truc" c'est que B.class est de type Class<B> et non pas Class<B<?,?>>, et il y a bien une différence entre les deux et ils ne sont pas compatible même s'ils peuvent sembler similaire :
- Class<B<?,?>> correspond à une classe B dont on ne connait pas les types paramétrés.
- Class<B> correspond au raw-type, c'est à dire sans aucun type paramétré.
Donc dans ton cas il faudrait plutôt déclarer la méthode comme ceci :

Code:

public void foo(Class<? extends B> arg) {}

Mais... c'est un usage "unsafe" qui génèrera un warning.

D'où ma nouvelle question : à quoi cela doit-il te servir ?
Que va tu faire de cet objet Class ?

a++
11/10/2016, 20h22
shaiHulud

Merci bcp pour l'explication !

Cela me sert à vérifier que les paramètres génériques du B que je vais assigner à A<K,V> sont bien cohérents avec K et V.
En particulier si une autre méthode de B renvoie des K et des V, je veux être sur de les manipuler en tant que K et V dans la classe A.

Maintenant, je suis en train de réaliser que les setters auxquels je communique ces classes sont declarés avec des raw types.
Mais quand bien même, n'est ce pas la bonne approche pour effectuer les vérifications dont je parle au compile-time ?
11/10/2016, 21h26
adiGuba

Mais concrètement : comment tu te sert de l'argument "Class" de la méthode foo() ?

Parce que si tu utilises des raw-types ou des <?> tu ne vérifies rien du tout.
De même que si tu utilises un type au lieu d'une instance : le fait de passer un OutputFormat.class ne te permet pas d'assurer quoi que ce soit.

a++
12/10/2016, 11h38
shaiHulud

Concrètement, j'envoie ces classes à des setters du framework Hadoop. Ce framework va instancier ces différentes classes sur différentes JVM.
Il s'avère que ces setter sont déclarés avec le raw type, ce qui fait qu'on a parfois au runtime des erreurs du genre "l'objet n'est pas du type attendu".
C'est pour éviter ces erreurs au runtime que j'essaie de typer mes arguments avec ces bounds (ni raw ni wildcard), de sorte que ce soit vérifié au compile-time.

Citation:

le fait de passer un OutputFormat.class ne te permet pas d'assurer quoi que ce soit.

Efffectivement, je voudrais passer "OutputFormat<String,String>.class", qui n'a pas de sens (à moins que je me mette à extraire au runtime les paramètres génériques de la classe...).
Du coup il me semble que je n'arriverai pas à garantir les types au compile-time...

Malheureusement tu ne peux pas vraiment mélanger reflection, Generics et covariance et avoir en même temps un compile typesafe...

Je ne connais pas trop Hadoop, mais je suppose qu'elle utilise la reflection pour créer des instances.
Pour moi le problème vient de là : il aurait été préférable d'utiliser une factory à la place.

A la rigueur si tu englobes l'appel à Hadoop, tu peux utiliser une factory dans ton code, et l'utiliser pour créer une instance dont tu récupèreras la classe :
Exemple :
Code:

1 2 3 4 5 6 7 8 9 10 11 public static class A<K,V> { // public void foo(Class<? extends B<?,?>> arg) {} public void foo(Supplier<B<? extends K,V>> factory) { // factory.get() crée une nouvelle instance : Class<? extends B> arg = factory.get().getClass(); // ... } }
:arrow: Mais attention car cela va créer une instance "inutilement". Je ne sais pas si c'est gênant ou pas.

L'avantage c'est qu'avec Java 8 et les références de méthodes, cela s'utilise aussi facilement (on peut utiliser LaClass::new pour obtenir une factory qui appelle le constructeur) :
Code:

1 2 3 4 5 6 7 8 9 A<String,String> a1 = new A<>(); a1.foo(B::new); // ok a1.foo(C::new); // ok a1.foo(D::new); // ok A<Date,Date> a2 = new A<>(); a2.foo(B::new); // ok a2.foo(C::new); // ok a2.foo(D::new); // erreur
a++

13/10/2016, 12h13
shaiHulud

Merci adiGuba,

Effectivement, l'approche par factory me permet le compile-time check car j'englobe tous les appels à hadoop.
Son seul défaut est de m'obliger à créer une factory pour toutes les classes que je dois envoyer aux différents setters (il y en a un paquet).

Par contre, ce sont les factory qui sont typées, donc on ne peut pas garantir qu'elles vont renvoyer ce qu'on attends (il me semble ?)...
Mais on a au moins séparé les responsabilités.

Je mentionne juste une autre approche pour être complet : vérifier par instrospection les paramètres génériques déclarés.
Ca reste du compile-time, mais ca peut être fait très tôt (avant que je communiques ces classes à hadoop, donc bien avant que les jobs soient lancés).

Encore merci !
13/10/2016, 15h07
adiGuba

Citation:

Envoyé par shaiHulud

Effectivement, l'approche par factory me permet le compile-time check car j'englobe tous les appels à hadoop.
Son seul défaut est de m'obliger à créer une factory pour toutes les classes que je dois envoyer aux différents setters (il y en a un paquet).

Si tu utilises les références de méthode tu n'en as pas besoin puisque tu peux utiliser la syntaxe NomDeLaClasse::new ;)

Citation:

Envoyé par shaiHulud

Par contre, ce sont les factory qui sont typées, donc on ne peut pas garantir qu'elles vont renvoyer ce qu'on attends (il me semble ?)...
Mais on a au moins séparé les responsabilités.

Comment pourraient-elles renvoyer autre chose ???

Citation:

Envoyé par shaiHulud

Je mentionne juste une autre approche pour être complet : vérifier par instrospection les paramètres génériques déclarés.
Ca reste du compile-time, mais ca peut être fait très tôt (avant que je communiques ces classes à hadoop, donc bien avant que les jobs soient lancés).

Oui mais cela pourrait être plus complexe à mettre en place pour gérer les différents cas d'héritage/implémentation...

a++
13/10/2016, 15h37
shaiHulud

Citation:

Comment pourraient-elles renvoyer autre chose ???

Si le factory.get() est declaré comme (B est l'équivalent du B que je définis dans l'exemple PipoTest)

Code:

Class<? extends B> get()

Comment peux-tu implémenter celle qui renvoie C<String,String> ou D (toujours dans mon exemple PipoTest) ?
13/10/2016, 20h02
adiGuba

Non je parlais d'une factory qui retourne directement une instance, pas une Class... sinon on se retrouve avec le même problème.

Car là tu peux vraiment restreindre les types paramétrés :

Supplier<B<K,V>> : les types K,V doivent être identique
Supplier<B<? extends K, ? extends V>> : les types K,V peuvent correspondre à des classes filles
Supplier<B<? super K, ? super V>> : les types K,V peuvent correspondre à des classes parentes
Supplier<B<? extends K, ? super V>> : le type K peut correspondre à une classe fille, et V peut correspondre à une classe parente
...

a++
14/10/2016, 11h05
shaiHulud

D'accord. Ca oblige effectivement à instancier les classes que je passe... pas très efficace pour les gros objets.
Ca doit être faisable dans la cas d'objets Hadoop, mais j'ai tellement peu l'habitude d'instancier moi même ces objets que je dois aller voir les args des constructeurs. J'espère qu'ils ont tous un constructeur ou factory publique.

Par contre je trouve ca amusant (mais finalement assez logique après tes explications) que le type-safety soit assuré au runtime !

Merci bcp !