Community
Participate
Working Groups
When the compiler warning/error "Signal overriding or implementing deprecated method" is turned on, warnings/errors are issues against immediate subclasses that override/implement a deprecated method, but they are not issues against all subclasses. It would seem helpful to issue the warning/error to all subclasses. Consider the following example: public class Base { /** * @deprecated */ public void foo() { //... } } public class Derived extends Base { public void foo() { // Warning/error posted against this method. //... } } public class Another extends Derived { public void foo() { // Warning/error NOT posted against this method. //... } } The class Another implements the method foo(), which is deprecated in Base, but does not get a warning/error issued against it. Clearly if you were to mark Derived's implementation of foo() as @deprecated then a warning/error would be issued against Another, but this is more work that you really want. Can this warning/error be propagated to all subclasses?
I suspect your problem to be a duplicate of bug 159709... Can you write a more detailed test case, try to edit the Base file, save it and see if the warning is still not shown on Another.foo() references? Thanks
Forget my previous comment... It's not a duplicate.
We do propagate from a method to direct overrides, not further down. Propagating further down could be expensive in term of performance.
While performance is always a concern, this could possibly be yet another checkbox preference under the "Deprecated API" compiler preferences, and be initially off. But before we assume that it would be a performance hit, can you please try it and see? As with so many performance related issues, it's not always easy to guess were the time is spent. It's worth remembering that Java class hierarchies are *typically* not more that two or three levels deep. I think this option will be helpful to people trying to clean up their code. It can be a little disconcerting when you're fixing warnings to see new warnings appear as you go. Changed severity to "enhancement", since this is not a bug exactly.
I'm not sure if the warning should really be deprecated. Looking at your test case, the author of Derived should really have observed the warning and fixed the issue by marking his overriding implementation of foo() deprecated as well. It could be that he did not do so intentionally, because he does want to continue supporting foo() in the future to his own clients. In other words, the author of "Derived" might want to live with the fact that clients of Base are not expected to call foo() because it's deprecated, but he still wants to support foo() to his own clients. It should not be a warning or error for his own clients to call foo(). If, on the other hand, the implementor of "Derived" had chosen to mark his own version of foo() deprecated as well, I think that he should not be bothered with a warning. In other words: the warning "...overrides a deprecated method" should not be issued for methods that are deprecated themselves.
+1 for Martin's comment.
