Is there a tool that can detect unused Java code based on a known set of "used" classes?

I am looking for a tool that can take a large set of classes and search them for unused methods/variables when given a set of seed classes. My goal is to re-refactor the large set of classes so I can extract only the needed stuff — which is used by the seed classes — from it.

When I say seed classes, I mean a set of classes to be used as entry point for figuring out what is unused. For instance, if class A calls class B and cl开发者_开发百科ass C calls class D, but the only seed class is class A, then class C and class D should both be considered unused classes. The tool I am looking for should be able to give the unused classes/methods/variables based on the set of seed classes. Does such a tool exist?

Eclipse's Java error/warning settings will help you find unused variables, through the Unused local or private member setting shown below. Unused method notifications should be controlled by a similar setting.

The Unused import setting, right above the highlighted line in the screenshot, should help somewhat with finding unused classes, but not on the scale you want. To use your example, I don't think Eclipse will recognize classes C or D as unused, as I don't think it can differentiate between the "seed group" and the "large group."

You should take a look at CodePro Analytix

Semantic Designs (my company) has such a tool for Java 1.4. You designate a set of Java source files and essentially the seed classes. It returns two results:

• A list of declarations (and their precise source code locations) that are useless with respect to the seeds (including the transitive closure of dead).
• A revised version of the supplied code, with the dead declarations removed.

If you like what you see in the first set, you can use the modified code. If the first set lists something you thing should have been in the used list, add it to the seed set and run it again.

It assumes you aren't using arbitrary reflection (if you are, simply list those classes that might be inspected by reflection. No, no easy way out of this).

We're working on one for Java 1.5/6/7 and hope to complete it this summer. If someone was interested, we could make the 1.4 version available for experimentation.