Suppress deprecation warnings
jothi.pa...@gmail.com
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
Andrew Thompson
> ...I am using a deprecated class...
Why?
--
Andrew T.
pscode.org
jothi.pa...@gmail.com
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
Lew
jothi.pa...@gmail.com 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
Mike Schilling
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.
Lew
> 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
Mike Schilling
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.
John B. Matthews
"Mike Schilling" <mscotts...@hotmail.com> 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
...
--
John B. Matthews
trashgod at gmail dot com
<http://sites.google.com/site/drjohnbmatthews>
Lew
> $ 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
>> Interesting. I see that my implementation has a non-standard option to
>> suppress warnings by category. Is this widely available?
>>
>> ...
>> -Xlint:{all,deprecation,unchecked,fallthrough,path,serial,finally,-deprec
>> ation,-unchecked,-fallthrough,-path,-serial,-finally}Enable or disable
>> specific warnings
>> ...
Lew <l...@lewscanon.com> 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
John B. Matthews
<e72bff6e-74ca-4af3...@q2g2000vbr.googlegroups.com>,
Lew <l...@lewscanon.com> wrote:
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>