Suppress deprecation warnings

Discussion in 'Java' started by jothi.padmanabhan, Apr 13, 2009.

  1. If I am using a deprecated class inside another class and use
    SuppressWarnings("deprecation"), javac is working fine and does not
    complain. However, if I have a method in my class that takes a
    deprecated
    class as a parameter, javac seems to ignore the suppression and
    continues to
    print the warning. Any ideas on how this could be solved?

    $ cat A.java
    @SuppressWarnings("deprecation")
    public class A {
    public void f1 () {
    B b = new B("abc");
    b.fun();
    }

    public void f2(B b) {
    b.fun();
    }
    }

    $ cat B.java
    @Deprecated
    public class B {
    private String s;
    public B(String str) { s = str;}
    public void fun() { System.out.println(s);}
    }

    $ javac -g -verbose -Xlint A.java B.java
    ..
    ..
    A.java:8: warning: [deprecation] B in unnamed package has been
    deprecated
    public void f2(B b) {
    ^


    Is there a way to Suppress warnings when deprecated classes are used
    as arguments as well?

    Thanks,
    Jothi
     
    jothi.padmanabhan, Apr 13, 2009
    #1
    1. Advertisements

  2. Why?
     
    Andrew Thompson, Apr 13, 2009
    #2
    1. Advertisements

  3. We are in the process of transitioning our framework from an "old" api
    to "new" api. Classes from old api are marked deprecated. While in
    this transition mode, we just want to suppress warnings, as there are
    way too many that we might miss out any "non deprecated" warnings
    during our builds.

    Thanks
    Jothi
     
    jothi.padmanabhan, Apr 13, 2009
    #3
  4. jothi.padmanabhan

    Lew Guest

    Please do not top-post.

    It is better, one could argue, not to suppress these warnings in code, because
    then you get complacent and never fix them.
     
    Lew, Apr 13, 2009
    #4
  5. Presumably they'll get fixed when they start to cause actual problems.

    It's a good general point, though: having made a considered decision
    to live with some warnings (e.g. raw-type warnings, when a large body
    of code is being moved from 1.4. and 1.5 and it isn't practical to
    genericize all container usage at once.), it's useful to suppress
    them, so that they don't hide warning one does care about.
     
    Mike Schilling, Apr 20, 2009
    #5
  6. jothi.padmanabhan

    Lew Guest

    If you're going to all the trouble to add 'SuppressWarnings("unchecked")' all
    over one's code, why doesn't it make sense to go through the incremental extra
    effort to add type parameters instead?
     
    Lew, Apr 20, 2009
    #6
  7. Interesting. I see that my implementation has a non-standard option to
    suppress warnings by category. Is this widely available?

    $ javac -X
    ....
    -Xlint:{all,deprecation,unchecked,fallthrough,path,serial,finally,-deprec
    ation,-unchecked,-fallthrough,-path,-serial,-finally}Enable or disable
    specific warnings
    ....
     
    John B. Matthews, Apr 20, 2009
    #7
  8. jothi.padmanabhan

    Lew Guest

    If you don't use -Xlint at all, you get a warning about unchecked
    operations, but it only gives a summary that there are such
    operations, not the details about which code or which operations. If
    you use -Xlint:unchecked, then you get those details. I haven't yet
    tried -Xlint:-unchecked. If that completely suppresses the warning,
    or if you are satisfied to get the summary warning that comes with not
    using either option, then you're done and you don't have to mess with
    the source.
     
    Lew, Apr 20, 2009
    #8
  9. jothi.padmanabhan

    Lew Guest

    OK, now I know:

    $ javac -d ../build -Xlint:unchecked eegee/Generaw.java
    eegee\Generaw.java:58: warning: [unchecked] unchecked call to add(E)
    as a member
    of the raw type java.util.List
    unstrunges.add( 1 );
    ^
    1 warning

    $ javac -d ../build -Xlint:-unchecked eegee/Generaw.java
    Note: eegee\Generaw.java uses unchecked or unsafe operations.
    Note: Recompile with -Xlint:unchecked for details.
    Using "-Xlint:-unchecked" doesn't suppress the warning, just the
    details, and is equivalent to specifying neither "unchecked" nor "-
    unchecked". That might be enough. You don't get to forget that you
    are messing something up, but you don't get overwhelmed by the
    warnings, either.

    Given that raw types leave your code vulnerable to exceptions at run
    time, you shouldn't forget the technical debt that they incur.
     
    Lew, Apr 20, 2009
    #9
  10. Aha. I was thinking of code I'd migrated to 1.5 in which I wanted to
    omit the deluge of serial warnings while I addressed the unchecked
    warnings first. I see javac leaves a reminder for the more serious
    warnings, unchecked & deprecated, while serial, fallthrough & finally
    can remain completely suppressed.
    Agreed.

    <evil>
    package news;

    import java.io.Serializable;
    import java.util.ArrayList;
    import java.util.Date;

    public class LintTest implements Serializable {

    // Warning: contains methanethiol
    public static void main(String args[]) {
    new Date(2009, 3, 1);
    new ArrayList().add("Test");
    try {
    switch (0) {
    case 0: ;
    case 1: ;
    }
    } catch(Error e) {
    return;
    } finally {
    return;
    }
    }
    }
    </evil>
     
    John B. Matthews, Apr 20, 2009
    #10
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.