Identify unused methods??

[alejandrina]

HI all,

We would like to use a tool to spot methods in oour packages that are
not being used. We have the entire source set under Eclipse, so a
plugin would be best. We do not want anything too complex or a graph,
or statistics, just a simple report that indicates what methods are not
used. Does anyone know of such a thing?

I did look in the usual places; I found code formatters, style
analyzers, code coverage tools...but no tool that does what I've
outlined.

Thanks,

Alejandrina

 

[Daniel Pitts]

HI all,

We would like to use a tool to spot methods in oour packages that are
not being used. We have the entire source set under Eclipse, so a
plugin would be best. We do not want anything too complex or a graph,
or statistics, just a simple report that indicates what methods are not
used. Does anyone know of such a thing?

I did look in the usual places; I found code formatters, style
analyzers, code coverage tools...but no tool that does what I've
outlined.

Thanks,

Alejandrina

I know in Idea you can do a source analysis, and set the options to
report unused methods.

What you should really do, however, is code coverage. That will tell
you everything that isn't used (including methods and branches).

 

[Manish Pandit]

You can install PMD plugin for eclipse
(http://pmd.sourceforge.net/eclipse/).

Including unused methods and variables, it will tell a lot more about
the code that you'd want to know

-cheers,
Manish

 

[alejandrina]

I thought code coverage had to do with run-time behavior (ie what paths
are not taken); what I wanted was static analysis. Am I wrong?

 

[alejandrina]

Hmmm. I looked at PDM but it said it dealt with *private* unused
methods. I need a project-wide usage report.

 

[alejandrina]

Yes, I was right, I think. I installed PMD and looked at the
violations. The only one (visual inspection only ) "unused method"
refers to private methods. Is there anything else I did not see?

Thanks,

Alejandrina

 

[Andreas Leitgeb]

I thought code coverage had to do with run-time behavior (ie what paths
are not taken); what I wanted was static analysis. Am I wrong?

You're not wrong. That's indeed a big difference.

I'm more the command-line freak and don't know much about
existing eclipse-plugins.

My approach to this task would be to use some class-file
disassembler on *all* class files (perhaps even on those
in the platform's rt.jar). Once you have a tree of
disassembled files, you can recursively grep for any method
or field names (fully qualified!) you wish to analyse.
Every field that doesn't appear with either "getfield"
or "putfield" is obviously unused.
Every static method that doesn't appear with "invokestatic"
is obviously unused.
Every method that doesn't appear with any of the invoke*
and that is an override of a baseclass' method is a candidate
that still needs to be checked for superclass invocations.

This is quite likely not the easiest way and I wish you that
there exists some plugin to your liking, but if not, this
hard way might be the only way that's left.

PS: there exist a couple of freeware java disassemblers.
PPS: javap is *not* a good choice, because it hides away
private method implementations.

 

[abose]

Doesn't Eclipse already mark all the unused methods/variables?
You might want to take a look at Findbugs
(http://findbugs.sourceforge.net/) also.

 

[Daniel Dyer]

You're not wrong. That's indeed a big difference.

I'm more the command-line freak and don't know much about
existing eclipse-plugins.

My approach to this task would be to use some class-file
disassembler on *all* class files (perhaps even on those
in the platform's rt.jar). Once you have a tree of
disassembled files, you can recursively grep for any method
or field names (fully qualified!) you wish to analyse.
Every field that doesn't appear with either "getfield"
or "putfield" is obviously unused.
Every static method that doesn't appear with "invokestatic"
is obviously unused.
Every method that doesn't appear with any of the invoke*
and that is an override of a baseclass' method is a candidate
that still needs to be checked for superclass invocations.

This is quite likely not the easiest way and I wish you that
there exists some plugin to your liking, but if not, this
hard way might be the only way that's left.

You can use Proguard for this. It is an obfuscator/shrinker, so it
already has to be able to work out which methods are not used. The
website even provides an example of how to get it list dead code:

http://proguard.sourceforge.net/manual/examples.html#deadcode


Dan.

 

[Daniel Pitts]

I thought code coverage had to do with run-time behavior (ie what paths
are not taken); what I wanted was static analysis. Am I wrong?

Please don't top post....

You are right, there is a difference between static analysis and
run-time behavior. I was suggesting code-coverage because it can give
you a much more complete picture of whats not being used. This, of
course, assumes that you have tests for all of your use cases. (unit
tests or otherwise), and that you don't have tests for situations that
AREN'T in your use cases.

In any case, there are plenty of static analysis tools out there that
will help find unused members. I already mentioned that stock IntelliJ
IDEA can do this. I would be surprised if there wasn't something for
Eclipse that could also.

Hope this helps,

Daniel.

 

[alejandrina]

Eclipse only marks the private unused methods...

I checked FindBugs, but it does not seem to trap this kind of error.
Thanks anyhow.

 

[alejandrina]

I may have to this route, but ONLY after I've exhausted other avenues


Alejandrina

 

[Don Roby]

Doesn't Eclipse already mark all the unused methods/variables?

Only private ones I believe.

I think there are a couple good reasons for this.

If you're developing a library, its public API may well be unused
internally, but you need it available for unknown and possibly not yet
existent external code, as that's the whole purpose.

If you're developing something to be called by a framework that exists
outside your code, calls to some of your public methods may only come
from that framework. I'd hate to get an "unused method" warning every
time I write a Servlet with a doPost method. And I rarely write code
that calls them...

And then there's reflection. Good luck!

The first might be covered if your codebase contains a good test suite
calling the public API.

The second issue might be covered if the container code is also included
in your project as a library, and its calls to the superclass methods
being implemented are detected as potential calls to your coded methods.

But I suspect it's somewhat intractable.

A tool that could detect such things might be nice for some cases, but
it should definitely be something you can disable to deal with these
cases and not get lots of spurious markings.

Eclipse does have a References pull-down that is useful for verifying
dead code once you have a suspect.

 

[Lew]

Please do not top post.

Eclipse only marks the private unused methods...

I checked FindBugs, but it does not seem to trap this kind of error.
Thanks anyhow.

Do you consider an unused public method an error, or am I misunderstanding the
point?

- Lew

 

[alejandrina]

We need to know what methods are unused so we can trim them from a
library before putting it under a strict revision control: therefore
we want the library to have ONLY what's needed. I do understand the
issues with reflection and we can deal with that too (manually )

Thanks,

Alejandrina

 

[Lew]

We need to know what methods are unused so we can trim them from a
library before putting it under a strict revision control: therefore
we want the library to have ONLY what's needed. I do understand the
issues with reflection and we can deal with that too (manually )

Thanks,

Alejandrina

Please do not top post.

But there is no way to know with a library, which by definition is built in
advance of use, to know which methods an application will use in the future.
If, say, none of your applications used. java.util.LinkedHashSet, and you were
their first customer, should Sun have removed it from their library before
they got their second customer?

- Lew

 

[alejandrina]

Let me explain better. This is NOT for a general-purpose library where
we don't know which methods will be used. Think of it as an embedded
system: once you've developed the code, and tested it, there may be
some code left behind that you may have used at some time but is no
longer needed and we want to remove it from the "embedded" version of
the library. AND even for true "utlity"-type methods, if we are not
using them in this version, we want to remove them from the "released
library".

You can do this with Eclipse, but manually, one method at a time. What
we're looking for is a report that operates on a library collection at
a time.

Alejandrina

 

[Tim B]

Let me explain better. This is NOT for a general-purpose library where
we don't know which methods will be used. Think of it as an embedded
system: once you've developed the code, and tested it, there may be
some code left behind that you may have used at some time but is no
longer needed and we want to remove it from the "embedded" version of
the library. AND even for true "utlity"-type methods, if we are not
using them in this version, we want to remove them from the "released
library".

You can do this with Eclipse, but manually, one method at a time. What
we're looking for is a report that operates on a library collection at
a time.

Alejandrina

please do not top post

To find unused methods this might work for you:
http://proguard.sourceforge.net/manual/introduction.html