Does anyone find 'find unused declaration' vaguely useful? 关注
I love the idea of this inspection, but the problem is that it's basically aimed at JavaSE apps and doesnt understand web frameworks or the idea of pojos (the same applies in fact for the 'declaration access can be weaker' inspection, which merrily whines about the getter/setter pattern).
There are a number of things that can make this inspection usable (aside from fixing the annotation exception list, which ignores all attempts at modifying it in7002), and this would be to be able to also add common superclasses that should be ignored.
So for example, I could add my web framework's base action class to this list, and I'd get rid of the few thousand warnings of unused declarations in all my action classes (which are used via custom tags, so nothing idea can pick up on).
Similary for getters and setters, there should be a toggle for disabling this check for properties, even if nothing is calling the getter, I'd still like it there and dont really want to be told to remove it.
The settings as they are now (field, variable, method, class) are fairly useless because they're so coarse grained.
Well, that is one reason why I try to avoid reflection where possible. One
just does not know when some method is called.
Uh, so I guess you don't use EE, hibernate, annotations, or write any kind of web application.
Hm, I think it's not as bad as you made it sound, but then again that's sort of your trademark, right?
For example Idea does recognize JSF/JSP EL.
Also I am using Seam and have configured the additional annotations like @In which is working ok. I do miss the option to mark a different set of annotations as "outjecting".
If you are using Spring and having problems with that I propose you file specific issues in Jira.
If you are using some exotic web framework, well you can't really blame Idea for that.
Still the common superclass to exclude is a good idea.
The industry has moved far enough in the last few years that there needs to be some good way of defining reflective access patterns for a project. I'd actually say it's worth a project-level config panel. We ran into this when we implemented the "Tighten Access Modifiers" functionality of InspectorGeneral. The best we came up with is to use the "Unused Declaration" inspections ideas of entry point, plus a few other standard cases, plus the ability to define annotations as indicating reflective access. It's workable, but could certainly be a lot more usable.
Sixth and Red River Software
"Code with Grace and Verve"
Generally yes (J2SE as you said). But I also use Wicket, because it (except
other issues) makes use of clean non-reflection-Java for nearly everything.
All other evaluated frameworks seemed to me too fragile.
Sometimes, e.g. for business objects, it could help if IDEA would allow
read-only source paths (causing refactorings to be prevented when touching
such code) which will be generated, e.g. by a pre-compile ANT-task.
The poor man's config panel would be a simple main class accessing all your
classes/methods which needs to be kept. Sorry, if this is not practical.