Suppress deprecation warnings

J

jothi.padmanabhan

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
 
J

jothi.padmanabhan

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
 
L

Lew

Please do not top-post.

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

Mike Schilling

Lew said:
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.
 
L

Lew

Mike said:
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?
 
J

John B. Matthews

"Mike Schilling said:
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
....
 
L

Lew

John said:
$ 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.
 
L

Lew

Lew said:
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.
 
J

John B. Matthews

Lew said:
Lew said:
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>
 

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. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,477
Members
44,898
Latest member
BlairH7607

Latest Threads

Top