IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
logo

FAQ Langage JavaConsultez toutes les FAQ

Nombre d'auteurs : 42, nombre de questions : 297, dernière mise à jour : 19 septembre 2017  Ajouter une question

 

Cette FAQ a été réalisée à partir des questions fréquemment posées sur le forum Java de http://java.developpez.com ainsi que l'expérience personnelle des auteurs.

Nous tenons à souligner que cette FAQ ne garantit en aucun cas que les informations qu'elle propose sont correctes. Les auteurs font leur maximum, mais l'erreur est humaine. Cette FAQ ne prétend pas non plus être complète. Si vous trouvez une erreur, ou que vous souhaitez nous aider en devenant rédacteur, lisez ceci.

Sur ce, nous vous souhaitons une bonne lecture.

SommaireEn développementWarnings (9)
précédent sommaire suivant
 

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.

Mis à jour le 29 septembre 2015 adiGuba

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 :

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

Ce message nous indique le problème potentiel : l'utilisation d'une méthode dépréciée dans ce cas. Il nous indique également la voie à suivre pour obtenir plus de détails sur ce problème : recompiler avec l'option -Xlint:deprecation. En effet, le JDK 5.0 a introduit une nouvelle option dans le compilateur javac afin de gérer l'affichage ou non des warnings : l'option -Xlint. Utilisée seule, elle permet d'activer tous les warnings du compilateur :

Code : Sélectionner tout
javac -Xlint MaClasse.java
L'option -Xlint accepte également les paramètres suivant :

Valeur Description
all Active tous les warnings.
deprecation Active les warnings concernant les éléments dépréciés. Il s'agit du même comportement que l'option -deprecation qui existait déjà dans les versions précédentes.
unchecked Active tous les warnings relatifs à l'utilisation des types paramétrés.
fallthrough Active la vérification des switch par le compilateur.
path Active les vérifications des chemins.
serial Active tous les warnings concernant la sérialisation (serialVersionUID).
finally Active tous les warnings concernant les blocs finally incorrects.
Par exemple :

Code : Sélectionner tout
javac -Xlint:all MaClasse.java

Plusieurs valeurs peuvent être utilisées en même temps en les séparant par des virgules :

Code : Sélectionner tout
javac -Xlint:deprecation,unchecked MaClasse.java

En précédant ces valeurs par un tiret (-), on désactive le warning associé :

Code : Sélectionner tout
javac -Xlint:all,-unchecked MaClasse.java

Mis à jour le 22 août 2005 adiGuba

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 :

Code Console : Sélectionner tout
Main.java:26: warning: [finally] finally clause cannot complete normally

Ce warning n'est actif qu'avec les options -Xlint ou -Xlint:finally.

Mis à jour le 29 septembre 2015 adiGuba

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 :

Code Console : Sélectionner tout
Main.java:5: warning: [serial] serializable class Main has no definition of serialVersionUID

Ce warning n'est actif qu'avec les options -Xlint ou -Xlint:serial.

Avertissement : ceci concerne également les classes qui héritent d'une classe qui implémente l'interface java.lang.Serializable, puisqu'elle devient elle-même sérialisable. Ainsi, ce warning concerne toutes les classes qui étendent les composants Swing[ par exemple…

Mis à jour le 22 août 2005 adiGuba

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 :

Code Console : Sélectionner tout
warning: [path] bad path element "../lib.jar": no such file or directory

Ce warning n'est actif qu'avec les options -Xlint ou -Xlint:path.

Mis à jour le 29 septembre 2015 adiGuba

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 :

Code Java : Sélectionner tout
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"); 
}

Si value vaut 1, alors le code des trois case sera exécuté, car il n'y a aucun break.

Si cette conception est autorisée par le langage, elle est toutefois fortement déconseillée, car elle complexifie l'utilisation du switch. Ainsi, le warning fallthrough, activé avec l'option -Xlint ou -Xlint:fallthrough permet de signaler l'absence du mot-clé break à la fin d'un case, et donc le « saut » possible au bloc case suivant :

Code Console : Sélectionner tout
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: 
                        ^

Note : ce warning peut également être activé sur les javac antérieures au JDK 5 avec l'option -Xswitchcheck.

Mis à jour le 29 septembre 2015 adiGuba

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 :

Code Console : Sélectionner tout
1
2
Note: Main.java uses unchecked or unsafe operations. 
Note: Recompile with -Xlint:unchecked for details.

Ce warning peut ainsi être affiché dans sa forme détaillée avec l'option -Xlint:unchecked, ce qui donne par exemple :

Code Console : Sélectionner tout
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");

Dans cet exemple, on utilise la méthode add() de l'interface java.util.List sans avoir paramétré son type. Concrètement, ce warning apparaît avec le code suivant :

Code Java : Sélectionner tout
1
2
List list = new ArrayList(); 
list.add("string");

La raison est simple, l'interface java.util.List et la classe java.util.ArrayList qui l'implémente sont désormais paramétrées. Elles doivent donc être utilisées en utilisant les Generics :

Code Java : Sélectionner tout
1
2
List<String> list = new ArrayList<String>(); 
list.add("string");

L'utilisation de la liste est ainsi sécurisée, car le compilateur vérifiera que seuls des objets de type String y sont ajoutés…

Mis à jour le 29 septembre 2015 adiGuba

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 :

Code Console : Sélectionner tout
1
2
Note: Main.java uses or overrides a deprecated API. 
Note: Recompile with -Xlint:deprecation for details.

Ce warning peut ainsi être affiché dans sa forme détaillée avec l'option -Xlint:deprecation. Il affichera ainsi l'élément concerné par la dépréciation :

Code Console : Sélectionner tout
1
2
Main.java:7: warning: [deprecation] getYear() in java.util.Date has been deprecated 
                return d.getYear();

Il faut ensuite consulter la documentation de la classe ou de la méthode concernée afin de connaitre la solution de remplacement.

Note : il est possible d'activer ce warning avec une version de javac antérieure au JDL 5 en utilisant l'option -deprecation.

Mis à jour le 29 septembre 2015 adiGuba ClaudeLELOUP

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 :

Code Java : Sélectionner tout
1
2
3
4
@SuppressWarnings("serial") 
class MyFrame extends javax.swing.JFrame { 
    [...] 
}

Ou encore afin d'utiliser une classe ou méthode dépréciée sans avertissement :

Code Java : Sélectionner tout
1
2
@SuppressWarnings("deprecation") 
java.util.Date date = new java.util.Date(2007, 1, 1);

L'annotation attend en paramètre le(s) nom(s) des warnings à ignorer. Les JDK officiel de Sun et d'Oracle utilisent principalement les avertissements suivants : deprecation, unchecked, fallthrough, path, serial et finally. Toutefois d'autres compilateurs peuvent très bien utiliser d'autres types de warning. Si un nom de warning est inconnu pour le compilateur, il se doit de l'ignorer.

Attention : cacher un warning ne veut pas dire que le problème est résolu, et ne devrait être utilisé qu'en dernier recours s'il n'existe vraiment pas d'autre solution.

Il faut également faire attention à bien positionner l'annotation, qui agit sur l'élément dans sa totalité. Si elle est positionnée devant une déclaration de variable cela ne concernera que cette ligne, mais devant une méthode ou une classe cela concernera la totalité de cette dernière, et cela risquerait de cacher d'autres warnings plus problématiques.

Il faut donc toujours essayer de limiter le plus possible la zone d'effet de l'annotation @SuppressWarnings, par exemple en créant une méthode simplement destinée à recevoir le code en question.

Remarque : bien que comprise dans les spécifications du JDK 5, cette annotation n'est effectivement supportée par le compilateur officiel du JDK de Sun qu'à partir du JDK 5.0 update 6.

Mis à jour le 29 septembre 2015 adiGuba

Proposer une nouvelle réponse sur la FAQ

Ce n'est pas l'endroit pour poser des questions, allez plutôt sur le forum de la rubrique pour ça


Réponse à la question

Liens sous la question
précédent sommaire suivant
 

Les sources présentées sur cette page sont libres de droits et vous pouvez les utiliser à votre convenance. Par contre, la page de présentation constitue une œuvre intellectuelle protégée par les droits d'auteur. Copyright © 2024 Developpez Developpez LLC. Tous droits réservés Developpez LLC. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents et images sans l'autorisation expresse de Developpez LLC. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.