Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Suppress deprecation warnings

Reply
Thread Tools

Suppress deprecation warnings

 
 
jothi.padmanabhan@gmail.com
Guest
Posts: n/a
 
      04-13-2009
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
 
Reply With Quote
 
 
 
 
Andrew Thompson
Guest
Posts: n/a
 
      04-13-2009
On Apr 13, 8:35*pm, (E-Mail Removed) wrote:
> ...I am using *a deprecated class...


Why?

--
Andrew T.
pscode.org
 
Reply With Quote
 
 
 
 
jothi.padmanabhan@gmail.com
Guest
Posts: n/a
 
      04-13-2009
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 <(E-Mail Removed)> wrote:
> On Apr 13, 8:35*pm, (E-Mail Removed) wrote:
>
> > ...I am using *a deprecated class...

>
> Why?
>
> --
> Andrew T.
> pscode.org


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      04-13-2009
Please do not top-post.

http://www.velocityreviews.com/forums/(E-Mail Removed) 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
 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      04-20-2009
Lew wrote:
>
> (E-Mail Removed) 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.


 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      04-20-2009
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
 
Reply With Quote
 
John B. Matthews
Guest
Posts: n/a
 
      04-20-2009
In article <4ZUGl.16022$(E-Mail Removed)>,
"Mike Schilling" <(E-Mail Removed)> 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>
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      04-20-2009
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
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      04-20-2009
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 <(E-Mail Removed)> 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
 
Reply With Quote
 
John B. Matthews
Guest
Posts: n/a
 
      04-20-2009
In article
<(E-Mail Removed)>,
Lew <(E-Mail Removed)> 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 <(E-Mail Removed)> 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>
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Deprecation warnings (2.7 -> 3 ) rusi Python 5 12-10-2010 04:25 PM
Python 2.6 Deprecation Warnings with __new__ Can someone explain why? rh0dium Python 7 10-26-2009 05:55 PM
suppress all Warnings and errors in Modelsim simulation neo_anderson VHDL 0 03-13-2008 09:35 AM
suppress ruby warnings during runtime? Aaron Smith Ruby 3 08-26-2007 10:41 PM
how to suppress the "source code echo" output by warnings.warn("x")? funkyj Python 2 05-19-2006 09:03 PM



Advertisments