Java : @SuppressWarnings démystifié
L’annotation @SuppressWarnings
permet de signaler au compilateur que l’on a conscience de réaliser une opération risquée, et qu’il peut donc arrêter de signaler un éventuel problème. Si l’annotation est standard, ses valeurs sont en revanche dépendantes du compilateur (d’après la JLS §9.6.1.5, seule “unchecked
” est standard), car ils n’ont pas tous les mêmes capacités d’analyse statique du code.
L’annotation @SuppressWarnings
possède la définition suivante :
-
@Target(value={TYPE,FIELD,METHOD,PARAMETER,CONSTRUCTOR,LOCAL_VARIABLE})
-
@Retention(value=SOURCE)
-
public @interface SuppressWarnings
On voit qu’elle peut s’appliquer aux classes, à leurs méthodes et propriétés, et même aux variables locales et aux paramètres de méthodes.
On l’utilise comme ceci :
-
@SuppressWarnings(“unchecked”)
-
public List<User> getUsers()
-
{
-
// Cast non vérifié
-
return (List<User>) new ArrayList();
-
}
Voyons maintenant les valeurs supportées par javac et Eclipse.
Javac
Avec le compilateur standard de Sun, version 1.6.0_11, on peut obtenir les valeurs supportées à l’aide de la commande :
-
javac -X
Ce qui donne :
all
: tous les warningscast
: les casts hasardeuxdeprecation
: utilisation de classes et méthodes obsolètesdivzero
: possible division par zéroempty
: ?unchecked
: conversions entre types paramétrés et types brutsfallthrough
: possible oubli d’un “break” dans un bloc “case”path
: ?serial
: oubli du SerialVersionUid dans une classe déclarée Serializablefinally
: le bloc finally ne se termine pas correctement (lancement d’une exception par exemple)overrides
: ?
Eclipse
Eclipse, qui possède son propre compilateur interne, fournit dans sa documentation la liste des valeurs qu’il reconnaît (je vous laisse l’explication originale en anglais) :
all
: to suppress all warningsboxing
: to suppress warnings relative to boxing/unboxing operationscast
: to suppress warnings relative to cast operationsdep-ann
: to suppress warnings relative to deprecated annotationdeprecation
: to suppress warnings relative to deprecationfallthrough
: to suppress warnings relative to missing breaks in switch statementsfinally
: to suppress warnings relative to finally block that don’t returnhiding
: to suppress warnings relative to locals that hide variableincomplete-switch
: to suppress warnings relative to missing entries in a switch statement (enum case)nls
: to suppress warnings relative to non-nls string literalsnull
: to suppress warnings relative to null analysisrestriction
: to suppress warnings relative to usage of discouraged or forbidden referencesserial
: to suppress warnings relative to missing serialVersionUID field for a serializable classstatic-access
: to suppress warnings relative to incorrect static accesssynthetic-access
: to suppress warnings relative to unoptimized access from inner classesunchecked
: to suppress warnings relative to unchecked operationsunqualified-field-access
: to suppress warnings relative to field access unqualifiedunused
: to suppress warnings relative to unused code
Du bon usage de @SuppressWarnings
Attention, la plupart du temps, le compilateur fait de son mieux pour vour prévenir d’erreurs de programmation pouvant mener à des bugs difficiles à détecter et corriger. Ne désactivez donc pas les alertes à moins de réellement savoir ce que vous faites !
Par exemple, il est fréquent d’oublier le champ SerialVersionUID
dans les classes sérialisables. Eclipse le signale, et c’est agaçant ; de nombreux développeurs désactivent donc cet avertissement. Pourtant, il est plus prudent de le prendre en considération, afin d’éviter des problèmes d’incompatibilité entre différentes versions d’une même classe lors d’opérations réseau par exemple.
Si toutefois vous êtes certain de vouloir ignorer un warning, documentez votre choix. Les équipes de maintenance vous en seront reconnaissantes !
Enfin une explication claire en Français, ça fait plaisir ! Merci
tout d’ abord je vous remercie pour l’article .
mais la question qui se pose ,pourquoi le compilateur nous indique ce type de warning ! et dans quel cas ?
cordialement
merci
Bonjour,
j’ai l’impression que la liste des warnings a évolué depuis : par exemple, avec Eclipse Indigo et un JDK 1.6, le cast de collections non typée doit être ignoré par :
@SuppressWarnings(“rawtypes”)
et non plus par :
De plus, si on veut ignorer plusieurs types de warnings sans pour autant mettre “all” en argument, on peut les spécifier dans un tableau, comme ceci (je reprends mon exemple, afin d’ignorer unchecked et rawtypes, pour que ça s’applique dans tous les environnements de travail) :
@SuppressWarnings( { “unchecked”, “rawtypes” } )
Il y a un problème de rendu avec la page: je vois tout en gris le colonne des options pour les warnings.