Discussion :

[rozwel]

Je decouvre encore des trucs avec les nouvelles syntaxes introduites dans Java 5 avec les Generics. Je viens de tomber par exemple sur l'API de la methode Collections.sort() : ca signifie quoi cette syntaxe au niveau du type de retour ? c'est "void" ou bien le "<T extends...>".

Et du coup j'ai ce code qui me donne un avertissement dans Eclipse mais je ne sais pas comment le corriger :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
List<Truc> list = buildList();
Collections.sort(list); //-> Type safety : unchecked invocation

[Gfx]

public static <T extends Comparable<? super T>> void sort(List<T> list)

Cela signifie que la methode sort() est parametree par un type T.

<T extends Comparable<? super T>>

Cela signifie que le type T doit implementer l'interface Comparable.

Comparable<? super T>

Cela signifie que l'interface Comparable implementee doit etre parametree par un type inconnu parent de la classe T.

Ton warning signifie que ta classe Truc implemente juste Comparable sans type. Tu dois faire cela :

class Truc implements Comparable<Truc>

Tu peux aussi changer Comparable<Truc> en Comparable<UneClasseParenteDeTruc>.

P.S : Lis cet excellent tutorial de Sun sur les generics : http://java.sun.com/j2se/1.5/pdf/generics-tutorial.pdf

[rozwel]

Merci beaucoup, super explication, super tutorial.

[xavlours]

Ton warning signifie que ta classe Truc implemente juste Comparable sans type.

Je suis encore en 1.4, alors je me demande :
en 1.5, si on déclare class Truc implements Comparable, on risque d'avoir des warnings,
alors que si on déclare class Truc implements Comparable<Object> on en aura pas ??
:

[Gfx]

Oui, c'est exact. En 1.4 l'interface Comparable definit la methode compareTo(Object) mais 1.5 definit Comparable<T> avec la methode compareTo(T). Du coup, si tu implementes Comparable<Object> tu te retrouves avec compareTo(Object) qui est compatible avec le code Java 1.4.

Il y'a d'autres solutions pour zapper les warnings. On peut compiler avec -Xlint:unchecked ou encore ajouter l'annotation @SuppressWarnings("unchecked"). Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
  @SuppressWarnings("unchecked")
  public static void main(String... args) {
    List<A> a = new ArrayList<A>();
    Collections.sort(a);
  }

[Glob]

Petite question sur le @SuppressWarnings:
c'est pas quand même un peu de la magouille de vouloir censurer le compilateur?

Ca me fait penser à ce sketch des Inconnus où le présentateur météo se fait flinguer parce qu'il n'y a pas que des soleils sur sa carte...

À quand le @SuppressErrors?

[Gfx]

Un warning n'est qu'un avertissement, si tu sais ce que tu fais je ne vois pas le probleme de les supprimer. D'autant plus que ca documente la suppression dans le code.

[adiGuba]

Salut,

Un warning n'est qu'un avertissement, si tu sais ce que tu fais je ne vois pas le probleme de les supprimer. D'autant plus que ca documente la suppression dans le code.

Tout à fait d'accord !
Surtout que Java 5.0 (et en particulier les Generics) a introduit un grand nombre de warning.

Ce qui est très bien car cela permet de prendre conscience d'un problème potentiel, et de l'analyser avant de finaliser l'application. Mais dans certains cas ce warning n'a pas lieu d'être ou est trop restrictif pour ton cas particulier, l'annotation @SuppressWarning permet alors d'obtenir une compilation propre.

Si demain tu compiles une application avec 80 warnings "inutile", il y a de forte chance que tu passes à coté d'un 81ème warning qui pourrait se présenter plus problématique...


Bien entendu il faut éviter de l'utiliser a tout bout de champs, et réduire au minimum sa portée (en évitant de le mettre sur des méthodes de 300 lignes...)



a++