Community
Participate
Working Groups
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/530.5 (KHTML, like Gecko) Chrome/2.0.172.43 Safari/530.5 Build Identifier: I20090522-1710 Given http://help.eclipse.org/galileo/index.jsp?topic=/org.eclipse.jdt.doc.isv/guide/jdt_api_compile.htm I would expect: class Overed { void foo() {} } class OverAnn extends Overed { @SuppressWarnings("over-ann") void foo() {} } ..to not want me to add the @Override annotation (or, more pertinently, not to add the @Override annotation on clean-up). Currently, it gives 'Unsupported @SuppressWarnings("over-ann")'. Note that @SuppressWarnings("all") does offer the expected behavior. Motivating example: Extending a class in a library. In one version, it has a method foo(String), in a newer, it has only foo(String, boolean). With the save-action of add-@Override, saving your class on a machine with one version of the library will cause the code not to compile on machines with the other. Actual example: FindBugs (oh, the irony). Reproducible: Always Steps to Reproduce: 1. Paste above code into any Java project. 2. Observe the warnings. 3. Clean-up: Add @Override and watch at it becomes.. ... @Override @SuppressWarnings("over-ann") void foo() {} ... java.version=1.6.0_14 java.vendor=Sun Microsystems Inc. BootLoader constants: OS=win32, ARCH=x86_64, WS=win32, NL=en_GB Command-line arguments: -os win32 -ws win32 -arch x86_64
over-ann is not one of the token supported fot SupressWarnings annotation. In general we consider that this is simple enough to fix not to add such token. Now if you have a test case that deserves to add this token, we might reconsider. Could you please give more details on the FindBugs library issue?
(In reply to comment #0) This I don't quite understand: > Motivating example: > > Extending a class in a library. In one version, it has a method foo(String), > in a newer, it has only foo(String, boolean). With the save-action of > add-@Override, saving your class on a machine with one version of the library > will cause the code not to compile on machines with the other. So, is your method foo(String) _intended_ to override an existing method as to leverage dynamic binding? Then it seems, that you need different versions of your class, too, to reflect the change in the library. If, on the contrary, you don't care for dynamic binding, then your method probably _shouldn't_ override an existing one, so you'd be better off with a new name for the new method and no overriding at all. Wanting to override a method from one version of the library and not wanting to override when compiling against a different version looks inconsistent to me, and thus I wouldn't suppress the warning but try to improve the program. But as Olivier said, seeing the exact real world example might help.
That was a shocking description, I'm sorry. :) The abstract class / method in question is http://findbugs.sourceforge.net/api/edu/umd/cs/findbugs/ResourceTrackingDetector.html#prescreen(edu.umd.cs.findbugs.ba.ClassContext, org.apache.bcel.classfile.Method, boolean). In FindBugs 1.3.9 this has the third boolean argument. In 1.3.8, it does not. An extension of this class can look something like: public boolean prescreen(ClassContext classContext, Method method) { return prescreen(classContext, method, false); } public boolean prescreen(ClassContext classContext, Method method, boolean mightClose) { doActualWork(); In 1.3.8, the first version is the @Override (and delegates to the three-argument version), in 1.3.9 the second is the @Override (leaving the two-argument version unreferenced). Simpler version: Usah wants to be able to implement either Inter1 or Inter2 depending on library version. Neither foo() nor foo(boolean) can be marked as @Override: interface Inter1 { void foo(); } interface Inter2 { void foo(boolean b); } class Usah implements Inter1 { /** helper for old version */ public void foo() { foo(true); } public void foo(boolean b) { System.out.println(b); } } This doesn't involve or require detection of which library version, etc... it feels like clean design to me?
I guess you meant: class Usah implements Inter1, Inter2 { ... I am not sure this is frequent enough to deserve a new token. As you say, using "all" is a workaround. Kent, any thoughts on this ?
I also don't see this as a 'common' enough case to add the additional token when @SuppressWarnings("all") can be used & is local to just the affected methods
Close enough. Meh, seemed like a silly omission at the time.
Closing as WONTFIX.
Verified for 3.6 M3
