Java 6: avertissement @SuppressWarnings (“rawtypes”) non pris en charge

J’ai déménagé sur une nouvelle machine qui contient le dernier compilateur Java de Sun et j’ai remarqué des avertissements dans le code Java 6 existant. L’IDE Eclipse, a suggéré que je annoter l’assignation avec:

@SuppressWarnings("rawtypes") 

Par exemple:

 class Foo { ... } ... @SuppressWarnings("rawtypes") Foo foo = new Foo(); 

Lorsque je suis revenu sur la machine avec l’ancien compilateur (JDK 1.6.0_20), j’ai remarqué que cet ancien compilateur avertit maintenant de la suppression des avertissements “rawtypes”, affirmant que cette suppression n’est pas prise en charge et propose de la remplacer par @SuppressWarnings (“non vérifié”). De plus, il y avait des endroits où le compilateur le plus récent, par défaut, me permettait de mettre à la fois des “non vérifiés” et des “rawtypes” – la compilation de ce code avec l’ancien compilateur reproduit le même avertissement.

Comment puis-je appliquer la compatibilité ascendante / descendante entre les deux, afin qu’aucun des compilateurs ne produise des avertissements?

Vous pouvez utiliser le @SuppressWarnings("unchecked") qui est supporté à la fois par le compilateur eclipse et par javac.

Mais rappelez-vous que l’annotation @SuppressWarnings est utilisée par votre compilateur qui peut avoir ses propres valeurs. Le JLS oblige uniquement le compilateur à comprendre les valeurs “non vérifiées” et “obsolètes” (pour le moment).

Les fournisseurs du compilateur doivent documenter les noms d’avertissement qu’ils prennent en charge conjointement avec ce type d’annotation. Ils sont encouragés à coopérer pour s’assurer que les mêmes noms fonctionnent sur plusieurs compilateurs .

Si vous utilisez Helios, vous devrez définir une option spécifique pour autoriser @SuppressWarnings("unchecked") au lieu de @SuppressWarnings("rawtypes") ,

S’il n’est pas possible de mettre à jour le code avec le nouveau jeton, la propriété système suppressRawWhenUnchecked=true peut être définie au démarrage d’Eclipse.


Ressources :

  • JLS – @SuppressWarnings ()
  • JDT Eclipse ( compilateur Java , nouveau jeton “rawtypes” pour l’annotation @SuppressWarnings )

EDIT: Voici l’article de knol maintenant indisponible qui a été utilisé comme référence, à l’origine écrit par Alex Miller .

@SuppressWarnings Annotation en Java

Annotation standard pour supprimer divers avertissements

L’annotation SuppressWarnings a été ajoutée en tant qu’annotation standard dans Java SE 5.

Définition

L’annotation @SuppressWarnings est définie dans la section 9.6.1.5 de la spécification du langage Java. Cette section indique:

Le type d’annotation SuppressWarnings prend en charge le contrôle du programmeur sur les avertissements émis par le compilateur Java. Il contient un seul élément qui est un tableau de Ssortingng . Si une déclaration de programme est annotée avec l’annotation @SuppressWarnings(value = {S1, ... , Sk}) , un compilateur Java ne doit pas signaler un avertissement identifié par l’un des S1, …, Sk si cet avertissement devait avoir ont été générés à la suite de la déclaration annotée ou de l’une de ses parties.

Les avertissements unchecked sont identifiés par la chaîne ” unchecked “.

La section suivante de @Deprecation mentionne également que ces avertissements peuvent être supprimés avec @SuppressWarnings("deprecation") .

Types d’avertissement valides

Les deux seules chaînes d’avertissement mentionnées dans la spécification sont “non vérifiées” et “dépréciées”. Cependant, Sun JDK utilise un ensemble de chaînes plus important dans le compilateur. Vous pouvez déterminer le jeu actuel en exécutant:

 javac -X 

qui vous montrera (entre autres choses) les parameters valides pour -Xlint.

Par exemple, Sun JDK 1.5 affiche:

  • all – supprime tous les avertissements de ce code
  • dépréciation – supprime les avertissements de code obsolète
  • non cochée – supprime les avertissements d’un appel non contrôlé ou d’une dissortingbution non contrôlée
  • fallthrough – supprime les avertissements si un commutateur tombe en panne sans trouver un cas valide (et pas de défaut)
  • chemin –
  • serial – supprime les avertissements si une classe Serializable ne définit pas un serialVersionUID
  • Finalement – supprime les avertissements de retour dans un élément final (qui ignorera le retour avec l’essai)

Et Sun JDK 1.6 ajoute:

  • jeter
  • divzero – supprime les avertissements si une division entière par zéro est détectée
  • vide
  • annule
  • aucun

Les IDE et les outils d’parsing statique prennent généralement en charge un grand nombre d’autres valeurs possibles pour @SuppressWarnings. Ces valeurs correspondent à des contrôles d’parsing statique spécifiques effectués par l’EDI.

Éclipse

Les valeurs d’avertissement Eclipse pour Eclipse 3.3 sont documentées dans les documents JDT .

  • tous – supprimer tous les avertissements
  • boxing – supprime les avertissements relatifs aux opérations de boxing / unboxing
  • cast – supprime les avertissements relatifs aux opérations de transtypage
  • dep-ann – supprime les avertissements relatifs aux annotations obsolètes
  • dépréciation – supprime les avertissements relatifs à la dépréciation
  • Fallthrough – supprime les avertissements relatifs aux pauses manquantes dans les instructions de commutateur
  • Finalement – supprime les avertissements relatifs au blocage final qui ne retourne pas
  • masquer – supprime les avertissements relatifs aux sections locales qui masquent la variable
  • incomplet-switch – supprime les avertissements relatifs aux entrées manquantes dans une instruction switch (enum case)
  • nls – supprime les avertissements relatifs aux littéraux de chaîne non-nls
  • null – supprime les avertissements relatifs à une parsing null
  • ressortingction – supprime les avertissements relatifs à l’utilisation de références déconseillées ou interdites
  • serial – supprime les avertissements relatifs au champ serialVersionUID manquant pour une classe sérialisable
  • static-access – supprime les avertissements relatifs à un access statique incorrect
  • plastic-access – supprime les avertissements relatifs à l’access non optimisé des classes internes
  • non cochée – supprime les avertissements relatifs aux opérations non contrôlées
  • access au champ non qualifié – supprime les avertissements relatifs à l’access aux champs sans réserve
  • inutilisé – supprime les avertissements relatifs au code non utilisé

IntelliJ

NetBeans

Exemples

Un exemple de spécification d’un seul avertissement:

 @SuppressWarnings("unchecked") public void methodWithScaryWarnings() { List rawList = new ArrayList(); List ssortingngList = (List)rawList; } 

Un exemple d’utilisation de deux avertissements:

 @SuppressWarnings({"unchecked","deprecation"}) public void methodWithScaryWarnings() { callDeprecatedMethod(); } 

Notez que Eclipse 3.5 ne comprend pas les rawtypes et signale un avertissement pour passer en mode non contrôlé. Il est frustrant que Eclipse ait proposé des annotations rawtypes qui posent plus de problèmes que la résolution. Ils auraient dû juste restr avec le standard.