Suppress deprecation warnings

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

  1. Guest

    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
    , Apr 13, 2009
    #1
    1. Advertising

  2. On Apr 13, 8:35 pm, wrote:
    > ...I am using  a deprecated class...


    Why?

    --
    Andrew T.
    pscode.org
    Andrew Thompson, Apr 13, 2009
    #2
    1. Advertising

  3. Guest

    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


    On Apr 13, 3:55 pm, Andrew Thompson <> wrote:
    > On Apr 13, 8:35 pm, wrote:
    >
    > > ...I am using  a deprecated class...

    >
    > Why?
    >
    > --
    > Andrew T.
    > pscode.org
    , Apr 13, 2009
    #3
  4. Lew Guest

    Please do not top-post.

    wrote:
    > 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.


    It is better, one could argue, not to suppress these warnings in code, because
    then you get complacent and never fix them.

    --
    Lew
    Lew, Apr 13, 2009
    #4
  5. Lew wrote:
    >
    > wrote:
    >> 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.

    >
    > It is better, one could argue, not to suppress these warnings in
    > code, because then you get complacent and never fix them.


    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. Lew Guest

    Mike Schilling wrote:
    > 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.


    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
    Lew, Apr 20, 2009
    #6
  7. In article <4ZUGl.16022$>,
    "Mike Schilling" <> wrote:

    > Lew wrote:
    > > Mike Schilling wrote:
    > >> 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.

    > >
    > > 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?

    >
    > It doesn't. Writing a filter to remove unwanted warnings, on the
    > other hand, can be quite efficient. This is another case where C# is
    > a bit nicer than Java -- you can suppress warnings by error number on
    > the compiler command line.


    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
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
    John B. Matthews, Apr 20, 2009
    #7
  8. Lew Guest

    John B. Matthews wrote:
    > $ javac -X
    > ...
    > -Xlint:{all,deprecation,unchecked,fallthrough,path,serial,finally,-deprec
    > ation,-unchecked,-fallthrough,-path,-serial,-finally}Enable or disable
    > specific warnings
    > ...


    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
    Lew, Apr 20, 2009
    #8
  9. Lew Guest

    John B. Matthews wrote:
    >> 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
    >> ...


    Lew <> wrote:
    > 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.


    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.

    > If ... you are satisfied to get the summary warning ... then you're done
    > and you don't have to mess with the source.


    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
    Lew, Apr 20, 2009
    #9
  10. In article
    <>,
    Lew <> wrote:

    > John B. Matthews wrote:
    > >> 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
    > >> ...

    >
    > Lew <> wrote:
    > > 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.

    >
    > 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.
    >
    > > If ... you are satisfied to get the summary warning ... then you're done
    > > and you don't have to mess with the source.

    >
    > 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.


    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.

    > Given that raw types leave your code vulnerable to exceptions at run
    > time, you shouldn't forget the technical debt that they incur.


    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
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
    John B. Matthews, Apr 20, 2009
    #10
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. funkyj
    Replies:
    2
    Views:
    496
    funkyj
    May 19, 2006
  2. neo_anderson
    Replies:
    0
    Views:
    899
    neo_anderson
    Mar 13, 2008
  3. rh0dium
    Replies:
    7
    Views:
    2,196
    Simon Forman
    Oct 26, 2009
  4. rusi
    Replies:
    5
    Views:
    461
  5. Aaron Smith
    Replies:
    3
    Views:
    147
    Johannes Held
    Aug 26, 2007
Loading...

Share This Page