Vous aimez ce que vous lisez sur ce blog ?
Envie d'aller plus loin avec véritable formation d'expertise en Java ?
Venez suivre ma formation Masterclasse Expertise Java !

"Même un développeur experimenté a besoin de continuer à apprendre. Et dans cette formation... j'ai appris beaucoup !" - A.G., Java Champion

Sessions intra-entreprises sur demande : contact[at]mokatech.net.
Inscrivez-vous vite !

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 :

  1. @Target(value={TYPE,FIELD,METHOD,PARAMETER,CONSTRUCTOR,LOCAL_VARIABLE})
  2. @Retention(value=SOURCE)
  3. 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 :

  1. @SuppressWarnings("unchecked")
  2. public List<User> getUsers()
  3. {
  4. // Cast non vérifié
  5. return (List<User>) new ArrayList();
  6. }

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 :

  1. javac -X

Ce qui donne :

  • all : tous les warnings
  • cast : les casts hasardeux
  • deprecation : utilisation de classes et méthodes obsolètes
  • divzero : possible division par zéro
  • empty : ?
  • unchecked : conversions entre types paramétrés et types bruts
  • fallthrough : possible oubli d'un "break" dans un bloc "case"
  • path : ?
  • serial : oubli du SerialVersionUid dans une classe déclarée Serializable
  • finally : 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 warnings
  • boxing : to suppress warnings relative to boxing/unboxing operations
  • cast : to suppress warnings relative to cast operations
  • dep-ann : to suppress warnings relative to deprecated annotation
  • deprecation : to suppress warnings relative to deprecation
  • fallthrough : to suppress warnings relative to missing breaks in switch statements
  • finally : to suppress warnings relative to finally block that don't return
  • hiding : to suppress warnings relative to locals that hide variable
  • incomplete-switch : to suppress warnings relative to missing entries in a switch statement (enum case)
  • nls : to suppress warnings relative to non-nls string literals
  • null : to suppress warnings relative to null analysis
  • restriction : to suppress warnings relative to usage of discouraged or forbidden references
  • serial : to suppress warnings relative to missing serialVersionUID field for a serializable class
  • static-access : to suppress warnings relative to incorrect static access
  • synthetic-access : to suppress warnings relative to unoptimized access from inner classes
  • unchecked : to suppress warnings relative to unchecked operations
  • unqualified-field-access : to suppress warnings relative to field access unqualified
  • unused : 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 !


Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.