Community
Participate
Working Groups
Build: Eclipse 3.0 M8 The Java > Compiler preference page for "Unused Code" contains options to check for the usage of deprecated API. The check box "Signal overriding or implementing deprecated methods" does not quite work as I would expect. For example consider the following interface and implemnting class: public interface IFoo { /** * @deprecated */ public void bar(); } public class Foo implements IFoo { public void bar() { // Necessary implementation of deprecated IFoo API // No-op } } The compiler places a warning marker against the Foo method bar(), which must be implemented since the class is an implementor of the IFoo interface. Of course failure to implement this method results in a compiler error. I think that it is unreasonable for the compiler to warn about this, since there is no reasonable alternative. Now consider the following additional type: public class Foo2 extends Foo { public void bar() { // Extends the Foo class' implementation. super.bar(); } } In this case, the compiler does NOT complain about the bar() method, even though it is extending the Foo class' implementation of bar(). This is also true if the bar() method overrides (ie, does not call super) the Foo class' implementation of bar(). I believe that the compiler should be complaining in this situation, because an inherited deprecated method is getting used/implemented.
Did you check the box "Signal overriding or implementing deprecated methods" ?
Cannot reproduce. If the check box is unchecked, no warning is issued when overriding/implementing a deprecated method. By default it is off. Concerning the other issue about 'super.bar();', a warning is correctly issued as expected. Note that deprecation warnings are never issued for code inside the same unit. Is it what you did ? Closing. Reopen if you can still reproduce it given my explanations.
Yes, I did check "Signal overriding or implementing deprecated methods". Yes, when this checkbox is unchecked a warning is not issues, which is the correct behavior. No, my example contains multiple compilation units. I shall attach a screen shot that clearly shows what I'm doing. The problem I'm describing is when the checkbox is checked, and you are: 1. Implementing an interface that contains a deprecated API. This should NEVER result in a warning, since there is no alternative, but it always does. 2. Overriding/extending a deprecated method in a superclass. Whether the superclass method is itself deprecated, or an implementation of a deprecated interface API is not important. This should ALWAYS result in a warning, but it never does. I removed the call to super(), since that's not important and is probably a distraction. Please see the attached screen shot. Thanks.
Created attachment 10956 [details] Screen shot
Simon, let me explain how this is meant to work. > 1. Implementing an interface that contains a deprecated API. This should > NEVER result in a warning, since there is no alternative, but it always does. We don't distinguish interface methods from any other (note that abstract methods from superclasses would be falling into the same category). The fact it is mandated by the API is true, but still it doesn't preclude from flagging this as an issue. Maybe it is time to consider switching to a different replacement API instead ? We could further offer some differenciation in between overriding/implementing abstract methods, but we wanted to keep the number of options reasonable; especially since it should be used in combination with the other option for not reporting deprecation in deprecated code (see below). > 2.Overriding/extending a deprecated method in a superclass. Whether the > superclass method is itself deprecated, or an implementation of a deprecated > interface API is not important. This should ALWAYS result in a warning, but > it never does. I removed the call to super(), since that's not important > and is probably a distraction. The method in Foo2 overrides a method from Foo which isn't deprecated, so no complaint is issued. --- I think you should start using the option for not reporting deprecation inside deprecated code. I believe it will express you exactly what you want. If you enable it, you will still see a warning against Foo, and none in Foo2. You can fix the warning in Foo by tagging the #bar() method as deprecated itself. This way, you acknowledged the fact you did override a deprecated method (for whatever reason), and propagate the deprecation flag to further dependents. Now, you should see no warning on Foo, and a warning on Foo2, since it now overrides a deprecated method. You can repeat the process on Foo2, so as to propagate the deprecation tag. Propagating the deprecation tag is a cleaner approach, since client code may not use the original method, and would never notice the deprecation in hierarchy: e.g. new Foo2().bar(); Closing since working as designed.
Thanks Philippe for taking the time to explain this to me. I really appreciate it. Yes, the propagation of deprecation is the right thing to do, and it is this that I missed. Thanks again.
No problem, glad someone uses our advanced deprecation warnings <g>
