Community
Participate
Working Groups
Purpose of this bug is to offer the capibility to the compiler not to complain on some specific warnings without unset corresponding global option. This would be a workaround solution for false positives waiting for fixes, but also allow user to be warnings free without changing the code and the offending option...
Solution should be based on some annotation file containing the necessary information, as opposed to constrain users to pollute their code with compiler specific pragmas (like $NON-NLS$).
Since you mention $NON-NLS$, are there any plans to intoduce a @NonNls annotation similar to IDEA? I know that @SuppressWarnings("nls") can be used but this is inferior in some ways. For example, when you do a "Find All References", it will show references to all @SuppressWarnings annotations. It's not hard to work around, but a @NonNls annotation seems like a useful addition.
Custom annotations are not the way we think of it. Annotation types need to be present on your classpath, and unless part of the standard libs, they are just tying user code to random IDEs... This is not our philosophy. A comment is more elegant in that respect, since it doesn't pollute user classpath. But search isn't finding comments very effectively (besides text/grep). BTW, re: @SuppressWarnings("nls"), one way to find these places is to turn off @SuppressWarnings (check compiler settings) and thus reveal them all back, so you can challenge them in this way.
When talking about annotation file, it was denoting some sort of auxiliary file containing text annotations that the compiler would understand to calibrate its diagnostics. This story could convey more information in the future, allowing to annotate third-party libs for which the information isn't supplied by the vendor (think of nullref analysis info).
(In reply to comment #3) > Custom annotations are not the way we think of it. > Annotation types need to be present on your classpath, and unless part of the > standard libs, they are just tying user code to random IDEs... > This is not our philosophy. This is a disadvantage, sure. But it does not have to tie the user to an IDE at all. A small jar with all annotations could be distributed and it would mean that there was no dependency on a given IDE (apart from the already existing one, other IDE users still see warnings when a $NON-NLS$ comment is used for example). This would also mean that @NotNull and @Nullable could be introduced making the null ref analysis stuff a lot more useful (it is useful right now, but the number of false positives is higher than I would have liked). And yes, I know that work is being done for 3.3 to improve this. :) Given how many external libraries most apps use these days, a very small additional jar would not be a problem in my view (some other people seem to think differently though). A separate annotation file can also do these things but it's far away from the code and has all the problems associated with that (there is a reason why so many people prefer java annotations over xml files for certain things). Being able to annotate a third party lib would be a nice feature though.
Having the extra JAR is doable, but only as long as it gets standardized. Also, it requires users to write Java5 code, which isn't a perfect solution either.
Good points.
How about moving this request to the Platforms Problems view? It shouldn't matter if the warning is from Java code, XML, or any other file type. It would just be nice if you could right-click on any item in the problems view and choose to ignore it. I like to have my warning levels "turned-up" to catch bad code but once I've looked at a specific warning I'd like to be able to choose to ignore it permanently (or maybe just for a session) so I don't have mentally filter the list every time.
>How about moving this request to the Platforms Problems view? This won't work as the compiler also issues problems during reconcile and on the AST.
And the hard thing is not how to suppress a specific warning, but how to update these external annotations when the targeted code changes. The solution would probably have to listen to text file buffers, add positions to the documents, and update/delete the positions when the text is changed. An unsolved problem is how to transfer external annotations when text is moved (e.g. by drag-and-drop or by refactorings such as extract method, move, pull up, ...)
