Summary: | Warning/error for "Signal overriding or implementing deprecated method" not propagated to all subclasses | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Simon Archer <sja.eclipse> |
Component: | Core | Assignee: | JDT-Core-Inbox <jdt-core-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | mober.at+eclipse |
Version: | 3.2 | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Simon Archer
2006-09-25 16:14:03 EDT
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. |