60

When I compile, javac outputs:

Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.`

I wish to suppress this warning. Trying -Xlint:none does not seem to help.

Dhanuka
  • 2,826
  • 5
  • 27
  • 38
IttayD
  • 28,271
  • 28
  • 124
  • 178
  • 4
    Why avoid it? You should replace calls to deprecated APIs with solutions that don't use a deprecated API. – Joachim Sauer Oct 12 '09 at 13:24
  • 29
    because i'm compiling modules of other developers with many lines of code. trying to convince them all to go over the code and fix it is futile. – IttayD Oct 14 '09 at 10:35
  • 1
    This is exactly my problem too. Until I have time to fix the warnings I'm doing a javac ... 2>&1 | grep -v "Note:" – Joseph Gordon Mar 16 '11 at 21:41
  • 2
    Why don't let the warning appear? It is a good reminder that something isn't as good as it could – Jaime Hablutzel May 15 '11 at 06:02
  • It makes sense to keep all uggly deprecation messages. This can help to convince other people to fix them properly. – mcoolive Feb 25 '15 at 18:16
  • 11
    The question is "How to do it", not "Do you think I shoud do it.'. Discussin on the "why" doesn't help. – Florian F Jul 11 '17 at 11:26
  • 7
    I agree that we should answer the question ("How") and not question the question ("Why?). That having been said, I will answer "why?" Sometimes we are dealing with codebases that use deprecated APIs and we have no control over it. If our build has 327 warnings about deprecations, and we accidentally introduce a NEW and REAL problem, the 328th warning will go un-noticed. That's WHY. – DaBlick Nov 06 '18 at 14:13
  • 1
    Yes, it's irritating when people pretend we live in an idealistic world. "Why do you want a cure for cancer? You shouldn't want it, you should accept that your parents will die." – Sridhar Sarnobat Oct 06 '20 at 00:20
  • I don't understand why many commenters say "you should replace calls to deprecated APIs". Why? I think you should cross that bridge when it comes, as long as an API call is deprecated but not removed it keeps working just fine and the deprecation warning is just annoying and may hide actually useful warnings. – nyholku Oct 10 '20 at 05:45

9 Answers9

40

From what I can tell in the docs, you can't do it on the command-line.

According to the javac documentation, -Xlint:none only disables warnings "not mandated by the Java Language Specification". It appears that warning you of the use of deprecated APIs is managed by the language spec.

Your best option would be to fix the use of deprecated APIs. However, an option would be to add the @SuppressWarnings("deprecation") annotation to the classes or methods that are using the deprecated APIs.

Lawrence Dol
  • 63,018
  • 25
  • 139
  • 189
Thomas Owens
  • 114,398
  • 98
  • 311
  • 431
  • 2
    For Jdk 5, I use -Xlint:all . This appears to suppress all the warnings of deprecation, unchecked, etc. – Abi Jun 30 '11 at 08:16
  • 7
    What if there are imports for deprecated classes?. Any option to hide such warnings? – Abhilash Jul 25 '13 at 13:13
  • 9
    There is at least one legitimate reason to suppress deprecation warnings, and that's when your framework provides a method which has been deprecated but which the framework itself invokes at some point because the deprecated method must continue to be supported until it's removed. – Lawrence Dol Nov 21 '15 at 00:33
29

Two possible ways:

  1. don't use deprecated API
  2. Use @SuppressWarnings("deprecation")
Joachim Sauer
  • 302,674
  • 57
  • 556
  • 614
  • 11
    1. don't use deprecated API; 2. think twice before using a deprecated API; 3. Use @SuppressWarnings("deprecation"). :) +1 – Bart Kiers Oct 12 '09 at 13:27
  • 33
    I asked how to turn off the warning. Obviously I can avoid using deprecated API, but since the code base involves two teams, I cannot persuade them all to do that. – IttayD Oct 14 '09 at 21:36
  • Who do we ignore compile warnings at the command line with javac? – Alexander Mills Feb 13 '19 at 23:42
  • 7
    I have a dream that one day I can ignore a warning without my motives being questioned. – Florian F Jan 09 '20 at 15:08
29

For others that were Google searching this problem and stumble upon this thread like I did...

Try: -Xlint:-deprecation

It seems to work on JDK 6... not sure about others.

Jeff
  • 307
  • 3
  • 2
  • 2
    Keeping in mind that this disables all deprecation warnings not just on selected methods. – John Weldon Feb 21 '13 at 21:59
  • At least icedtea8's javac accepts -Xlint:-deprecation only to ignore it. (i.e. deprecation warnings still produced.) – Bodo Thiesen Sep 07 '16 at 16:44
  • 3
    And you can use several lint settings together. My setup has `-Xlint:all -Xlint:-deprecation` so that everything except deprecation generates a warning. – Nate Glenn May 24 '17 at 08:04
  • 2
    I tried this (with JDK7, Gradle 4.8.1) and that annoying `Note:...` stilll appears. – Sridhar Sarnobat Oct 07 '20 at 22:45
  • 2
    This works for java 11.0.6 too, but there is difference between using "-Xlint:-deprecation" and "@SuppressWarnings("deprecation")" . With the Xlint method the warning is suppressed but you still get "Note --- uses or overrides a deprecated API". Which is also annoying at least in Eclipse/Ant cause it is emphasised in red in the console output. – nyholku Oct 10 '20 at 05:54
10

With Java 6, neither the @Depreated annotation, nor a comiler flag will help you here. The only solution that worked for me was to put a javadoc comment with the @deprecated (small caps) tag on the deprecated method:

/**
  * @deprecated overriding deprecated method
  */
@Override
public javax.xml.bind.Validator createValidator() throws JAXBException {...}

(The example is from a class that derives from JAXBContext.)

(I didn't import the deprecated Validator class to avoid a warning on the import statement.)

Wolfgang
  • 2,367
  • 23
  • 29
  • 2
    Thanks Wolfgang. The @SuppressWarnings("deprecation") annotation was not working completely, some of the warnings were still being output. Adding the @deprecated comment suppressed them all. – Eric Thorbjornsen Aug 01 '12 at 00:43
6

When using gradle you can configure it easily:

tasks.withType(JavaCompile) {
    options.deprecation = false
}

(tested with Gradle 2 and Java 8)

Arne Burmeister
  • 20,046
  • 8
  • 53
  • 94
  • Note: a few years later, with gradle 6, this doesnt work any more. The corresponding "isDeprecation" is false by default these days, and doesnt affect this warning – GhostCat Feb 15 '21 at 12:13
1

If it's a core Java API, there is almost certainly a replacement that will do what you want. Run the javac with that extra parameter, and then look at the API for the deprecated method and replace as appropriate.

Matt Poush
  • 1,263
  • 8
  • 11
0

use nowarn attribute see below

e.g.

<javac srcdir="src" 
  destdir="build/classes" source="1.6" 
  target="1.6" debug="true" encoding="Cp1252"
  nowarn="on">

by default nowarn attribute is off

astra03
  • 505
  • 1
  • 7
  • 18
-1

@SuppressWarnings("deprecation") is not working for me, instead I've used 

@SuppressWarnings("unchecked")
Kaushal28
  • 5,377
  • 5
  • 41
  • 72
-4

If you are compiling in the command line you can filter the messages with grep, just filtering out the messages that has unwanted content, like for example grep -v deprecated. You can use | to send the output to grep,

your compile command | grep -v deprecated
Ayman Salah
  • 1,039
  • 14
  • 35
mbd
  • 35
  • 4
  • 2
    That's really not practical in this case, as much as I appreciate the power of Unix pipes. A lot of tools don't play nicely with Unix Philosophy. – Sridhar Sarnobat Oct 06 '20 at 00:19
  • I agree, this is close to useless. It is super simple: when you do your own little self grown project where such grep -v solutions might work ... in such a setup, you dont ignore warnings, you fix them. And in any real world project where you have so many warnings that you want to suppress them, you arent compiling manually. – GhostCat Feb 15 '21 at 12:26