FAQ Langage JavaConsultez toutes les FAQ

Un warning ou avertissement est un message survenant à la compilation pour indiquer un problème potentiel, mais qui ne bloque pas le déroulement de la compilation. Il est toutefois conseillé de les corriger, car cela peut poser des problèmes à l'exécution.

Par défaut, les warnings ne sont pas tous affichés et seuls certains d'entre eux affichent une note pour signaler leur présence. Par exemple :

1
2
Note: Main.java uses or overrides a deprecated API.  
Note: Recompile with -Xlint:deprecation for details.

javac -Xlint MaClasse.java

javac -Xlint:all MaClasse.java

javac -Xlint:deprecation,unchecked MaClasse.java

javac -Xlint:all,-unchecked MaClasse.java

Ce warning signale qu'un bloc finally ne se termine pas correctement. En effet, un bloc finally ne devrait pas contenir d'instruction return puisqu'il peut être appelé en cas d'exception ou de retour dans le bloc try correspondant, ce qui fait que l'instruction return éventuelle du bloc try sera ignorée.

Ainsi, si un bloc finally comporte le mot-clé return, il sera signalé par ce warning, par exemple :

Main.java:26: warning: [finally] finally clause cannot complete normally

Ce warning signale qu'une classe qui implémente l'interface java.io.Serializable n'a pas défini de membre serialVersionUID. En effet, le membre serialVersionUID permet d'affecter un numéro de version à la classe. Ce numéro doit normalement être changé lorsqu'un champ non éphémère (qui n'est pas marqué transient) est ajouté ou supprimé de la classe. Théoriquement, c'est au développeur de gérer ce numéro de version ; toutefois, si ce champ est absent, le compilateur génèrera un numéro automatique.

Le champ serialVersionUID est utilisé lors de la désérialisation afin de s'assurer que les versions des classes Java soient concordantes. Si ce n'est pas le cas, une exception de type InvalidClassException sera générée. Or, il se trouve que le calcul des serialVersionUID par défaut est extrêmement sensible aux modifications apportées au code source et peut même varier selon les compilateurs. Ce qui a pour inconvénient de provoquer des InvalidClassExceptions inattendues lors de la désérialisation.

Il est ainsi fortement conseillé de gérer le serialVersionUID de toutes classes sérialisables, et bien sûr de modifier cette valeur lors d'un changement sur les champs de la classe. Ce warning signalera ainsi toutes classes qui implémentent l'interface java.lang.Serializable sans définition du serialVersionUID explicite :

Main.java:5: warning: [serial] serializable class Main has no definition of serialVersionUID

Ce warning permet d'afficher un message si les chemins (classpath, sourcepath, etc.) passés au compilateur javac sont inexistants. Il est ainsi très pratique pour vérifier que tous les éléments du CLASSPATH sont corrects. Ainsi, si un chemin est incorrect, il affichera le message suivant :

warning: [path] bad path element "../lib.jar": no such file or directory

Ce warning signale des erreurs possibles dans les blocs switch si l'on n'utilise pas de break à la fin de chaque case. En effet, dans le code suivant :

1
2
3
4
5
6
7
8
switch (value) { 
    case 1: 
        System.out.println("Un"); 
    case 2: 
        System.out.println("Deux"); 
    case 3: 
        System.out.println("Trois"); 
}

1
2
3
4
5
6
Main.java:19: warning: [fallthrough] possible fall-through into case 
                        case 2: 
                        ^ 
Main.java:21: warning: [fallthrough] possible fall-through into case 
                        case 3: 
                        ^

Ce warning signale qu'une classe ou une méthode paramétrée avec les Generics est utilisée sans indication du type paramétré, ce qui lui fait perdre la sécurisation des opérations apportée par les Generics. Si ce warning est désactivé, une note sera quand même affichée à la fin de la compilation, par exemple :

1
2
Note: Main.java uses unchecked or unsafe operations. 
Note: Recompile with -Xlint:unchecked for details.

1
2
Main.java:14: warning: [unchecked] unchecked call to add(E) as a member of the raw type java.util.List 
                list.add("string");

1
2
List list = new ArrayList(); 
list.add("string");

1
2
List<String> list = new ArrayList<String>(); 
list.add("string");

Ce warning signale toutes les classes ou méthodes dépréciées ou obsolètes, c'est-à-dire qui ne devraient plus être utilisées. Si ce warning est désactivé, une note sera quand même affichée à la fin de la compilation, par exemple :

1
2
Note: Main.java uses or overrides a deprecated API. 
Note: Recompile with -Xlint:deprecation for details.

1
2
Main.java:7: warning: [deprecation] getYear() in java.util.Date has been deprecated 
                return d.getYear();

En plus d'introduire de nouvelles fonctionnalités, le JDK 5 a introduit un grand nombre de nouveaux warnings afin d'indiquer un problème potentiel. Toutefois, il existe de nombreux cas où l'on ne peut pas faire autrement et ces warnings peuvent alors être assez dérangeants.

Il est heureusement possible d'utiliser l'annotation java.lang.SuppressWarnings afin de supprimer un warning en particulier. Par exemple, afin de supprimer le warning concernant l'absence de définition du serialVersionUID :

1
2
3
4
@SuppressWarnings("serial") 
class MyFrame extends javax.swing.JFrame { 
    [...] 
}

1
2
@SuppressWarnings("deprecation") 
java.util.Date date = new java.util.Date(2007, 1, 1);