Community
Participate
Working Groups
when placed on the class declaration, and it can't be moved above the import statement. For generated code, this can be a big distraction. (You can't move the annotation above the import statement.) Repro case: import java.io.InputStream; @SuppressWarnings("unused") public class Quack { }
Can't place the annotation in package-info.java either.
If this bothers you so much, why don't you run "Organize imports"? <g>
Well, yes if there was a user writing the file, who would hit Ctl Shift O that would be an option. But this is happening in generated code. And correcting their modeling in the generation logic to only import used types (at this point) is non-trivial. The end-user's organize-import gesture, if used in this case, would be overlaid in short order by the next dispatch of APT ...:)
@SuppressWarnings will never be able to address this, as it only acts on nested code. The only alternative would be to introduce another tag // $NO_WARN$ when generating the code, but I suspect it is as doable as having the generator not produce the offending import statement. I don't see us taking any action here. Pls reopen if you disagree.
I wonder if we couldn't treat import warnings as being part of the first type... it would change things a little bit, but likely for the best in the end. Note that using a single-type import, and targeting a deprecated type, the same symptoms can be reproduced with javac. ------------ X.java import p.A; @SuppressWarnings("all") public class X { void foo(A a) { } } ------------ p/A.java package p; /** @deprecated */ public class A { } ------------ javac says: X.java:1: warning: [deprecation] p.A in p has been deprecated import p.A; ^ X.java:5: warning: [deprecation] p.A in p has been deprecated void foo(A a) { The second warning feels a bug, as it should have been suppressed.
Added disabled test: AnnotationTest#test185.
Created attachment 33266 [details] Patch for Annotation Patch spanning the scope of @SuppressWarnings for first type declaration from beginning of unit to end of type (as opposed to from type start only). Note: it works for any sort of warnings: i.e. deprecation, raw type ref, unused imports
Should we consider this for inclusion for 3.2 ?
I think that makes sense.
Just addding another scenario that may be considerig when working on this issue: 1. Using M4, create a Java file, and use a deprecated class (IDOMNode for example) => Both the import and the line that uses the class should have the deprecation warning 2. Deprecate the class you've just created => The import has the deprecation warning IMHO, I think the warning at the import should go away so that the Java file itself is not "yellow" marked.
Good point, it should also be handled in a similar fashion for consistency purpose.
+1 for 3.2. This makes it a lot easier for people who generate java code (things like annotation processors and wsdl compilers for example), who otherwise will either spend a lot of energy generating warning-free code, or pollute the user experience with unnecessary warnings.
Ok, if we have consensus, I will reopen it and apply the patch. I will try to also solve the case in comment 10.
Created attachment 33308 [details] Patch for comment 10 scenario
Enabled AnnotationTest#test185. Added DeprecatedTest#test010 + variant with @Deprecated as AnnotationTest#test187 (but this one doesn't yet work with patch yet due to a separate issue in @Deprecated early resolution, see bug 124346).
Fixed
*** Bug 124697 has been marked as a duplicate of this bug. ***
Verified for 3.2 M5 using build I20060215-0010
Verified in M5. Thx for the fix.
