Maia: globally unused symbols

hi,

I really like this feature as it is revealing a whole new piece of valuable information as I read/write code.

As usual you are providing the suppress warnings possibility. I have a few packages with many many classes that are loaded by in-house reflection mechanisms. This results in many false positive and adding ignore warnings tags is something I usually want to keep for code-hacks or very exceptional situations.

any thoughts?


cheers,
Florian

4 comments
Comment actions Permalink

In the past we also used reflection to access our own business objects, but
maintenance became quickly a nightmare. After we have got rid of such
reflection, we can rely on the compiler again. If it compiles, all
methods/classes are there.

My recommendation: get rid of reflection. It creates more problems than it
solves.

0
Comment actions Permalink

While in principal I agree with you, this isn't always a practical solution
and there are many cases (eg framework code) where reflection is not only
justified, it's essential. Code that is instantiated by IoC containers like
Guice also suffer from this problem. I agree with Florian, a way to either
suppress the warnings or indicate that certain classes are instantiated via
a non-standard mechanism would be useful.

In the past we also used reflection to access our own business
objects, but maintenance became quickly a nightmare. After we have got
rid of such reflection, we can rely on the compiler again. If it
compiles, all methods/classes are there.

My recommendation: get rid of reflection. It creates more problems
than it solves.



0
Comment actions Permalink

Guest wrote:

I agree with Florian, a way to either
suppress the warnings or indicate that certain classes are instantiated via
a non-standard mechanism would be useful.


Let me make my suggestion clear. the latest EAP build does provide the possibility of adding the @SupressWarnings() annotation. I find this a little to fine-grained when this occurs in many classes. I also think it litters the code with extra information that is specific to one IDE.

It is not like using annotations for supressing standard compiler warnings which anyone looking at the code with any editor/IDE should be made aware of.


Florian

0
Comment actions Permalink

If you can isolate the code used by reflection in a specific source directory, then you can use the scope <-> inspection association to disable the global unused inspection for this particular directory.

I admit that it can be a daunting task, if classes accessed by reflection are all over the place in the codebase.
So i agree that it would be useful if some annotation (or javadoc tag, don't forget JDK1.4 users like me ) could be used to tell that the class/method/field is accessed by reflection.

If you post a Jira, i'll vote for it

Gilles

0

Please sign in to leave a comment.