Quand je compile, javac sort :
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.`Je souhaite supprimer cet avertissement. Essayer -Xlint:none ne semble pas aider.
D'après ce que je peux voir dans la documentation, on ne peut pas le faire en ligne de commande.
Según la javac documentation L'option -Xlint:none ne désactive que les avertissements "non exigés par la spécification du langage Java". Il semble que le fait de vous avertir de l'utilisation d'API dépréciées soit géré par la spécification du langage.
Votre meilleure option serait de corriger l'utilisation des API dépréciées. Cependant, une option serait d'ajouter l'option @SuppressWarnings("deprecation") aux classes ou méthodes qui utilisent les API dépréciées.
Pour Jdk 5, j'utilise -Xlint:all . Cela semble supprimer tous les avertissements de dépréciation, non vérifiés, etc.
Que faire s'il y a des importations pour des classes dépréciées ? Existe-t-il une option permettant de masquer ces avertissements ?
Il existe au moins une raison légitime de supprimer les avertissements de dépréciation, c'est lorsque votre framework fournit une méthode qui a été dépréciée mais que le framework lui-même invoque à un moment donné parce que la méthode dépréciée doit continuer à être supportée jusqu'à sa suppression.
Deux voies possibles :
@SuppressWarnings("deprecation")
1. n'utilisez pas d'API dépréciée ; 2. réfléchissez à deux fois avant d'utiliser une API dépréciée ; 3. utilisez @SuppressWarnings("deprecation"). :) +1
J'ai demandé comment désactiver l'avertissement. Il est évident que je peux éviter d'utiliser des API dépréciées, mais comme la base de code implique deux équipes, je ne peux pas les persuader toutes de le faire.
Gardez à l'esprit que cela désactive tous les avertissements de dépréciation et pas seulement sur les méthodes sélectionnées.
Au moins le javac d'icedtea8 accepte -Xlint:-deprecation seulement pour l'ignorer. (c'est-à-dire que les avertissements de dépréciation sont toujours produits).
Et vous pouvez utiliser plusieurs réglages de peluche ensemble. Mon installation a -Xlint:all -Xlint:-deprecation de sorte que tout ce qui n'est pas une dépréciation génère un avertissement.
Avec Java 6, ni l'annotation @Depreated, ni un drapeau du compilateur ne vous aideront ici. La seule solution qui a fonctionné pour moi a été de mettre une annotation Commentaire du javadoc avec le @deprecated (petites capitales) sur la méthode dépréciée :
/**
* @deprecated overriding deprecated method
*/
@Override
public javax.xml.bind.Validator createValidator() throws JAXBException {...}(L'exemple provient d'une classe qui dérive de JAXBContext).
(Je n'ai pas importé la classe Validator dépréciée pour éviter un avertissement sur l'instruction d'importation).
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
4 votes
Pourquoi l'éviter ? Vous devez remplacer les appels aux API dépréciées par des solutions qui n'utilisent pas d'API dépréciée.
26 votes
Parce que je compile des modules d'autres développeurs avec de nombreuses lignes de code. essayer de les convaincre tous de revoir le code et de le corriger est futile.
1 votes
C'est exactement mon problème aussi. En attendant d'avoir le temps de corriger les avertissements, je fais un javac ... 2>&1 | grep -v "Note :"
2 votes
Pourquoi ne pas laisser l'avertissement apparaître ? C'est un bon rappel que quelque chose n'est pas aussi bon qu'il pourrait l'être
0 votes
Il est logique de conserver tous les messages de dépréciation moche. Cela peut aider à convaincre d'autres personnes de les corriger correctement.
7 votes
La question est "Comment le faire", pas "Pensez-vous que je devrais le faire". Discuter du "pourquoi" ne sert à rien.
5 votes
Je suis d'accord pour dire que nous devrions répondre à la question ("Comment") et non à la question ("Pourquoi ?"). Ceci étant dit, je vais répondre à la question "pourquoi ?". Parfois, nous avons affaire à des bases de code qui utilisent des API dépréciées et sur lesquelles nous n'avons aucun contrôle. Si notre build comporte 327 avertissements sur les dépréciations, et que nous introduisons accidentellement un NOUVEAU et VRAI problème, le 328e avertissement passera inaperçu. C'est pourquoi.
0 votes
Oui, c'est irritant quand les gens prétendent que nous vivons dans un monde idéaliste. "Pourquoi veux-tu un remède pour le cancer ? Tu ne devrais pas le vouloir, tu devrais accepter que tes parents meurent."
0 votes
Je ne comprends pas pourquoi de nombreux commentateurs disent "vous devriez remplacer les appels aux API dépréciées". Pourquoi ? Je pense que vous devriez traverser ce pont quand il se présente, tant qu'un appel d'API est déprécié mais pas supprimé, il continue à fonctionner parfaitement et l'avertissement de dépréciation est juste ennuyeux et peut cacher des avertissements réellement utiles.