 |
History
| Log In
|
|
|
|
How should someone annotate a logging library, let's say log4j, with IDEA's annotation? Of course it's not impossible, but it creates an unjustifiable maintenance effort. And don't forget that currently Java 5 is quite far from being the widely used development platform. I'm happy that since just a few months I can rely on Java 1.4 and don't have to be 1.3 compatible any more in many projects.
I can't currently think of a more obvious example (at least amongst most of the currently available options) of non-nls strings than Logger.getLogger("something"). Even logging methods themselves are probably very rarely i18n'ed. Logging is such a fundamental aspect that I'd not say it is to be ignored "for some reason". There is however the problem of the different available logging toolkits, which might make it hard to configure. Because of this, and the general problem that annotating library methods is potentially impossible, there should be a generic configuration to specify which methods (which parameter) of a class should be ignored, maybe pre-configured for the most popular logging toolkits. Requiring to extract such literals passed to library methods into a variable/constant (IDEA-4818) and annotating it with NonNls, just because the tool (IDEA) can't deal with it otherwise, doesn't seem right to me. For what it worth we've created in-project log4j Logger wrapper with all proper annotations. As the matter of fact there are so many places one could take the advantage of using @NonNls it's very hard to resist
 Anyway we understant 1.4 compatibility issue so feel free to apply votes. The generic solution we've been thinking of is something called "external annotations" - the possibility to put annotations for some source code you don't control (JDK itself is the prime example, log4j may be another) in an external file. (The specific details on the format of the file and the way it should be edited are completely undecided.)
As this external file will not be a pure Java source file, there is no reason not to use it in 1.4 projects. I just want to chime in and ask that, in the search for a generic solution, the requirement to easily exclude logger methods from the hard coded strings inspetion doesn't get lost.
Emphasis on "easily". : ) We already have a very nice solution for the easiness problem - all the complexity of external annotations will be taken care of by the quickfix for the inspection.
Any news on whether those "external annotations" will appear in Demetra?
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Normal
'Hard Coded Strings' inspection needs to be able to ignore logger
(The annotation lets us avoid creating dozens of options for the inspection, for every possible case of string literals that someone somewhere wants to ignore for some reason.)