Dead Code Detector for Guice/Gin modules?

Question

Usual dead code detectors don't seem to find which defined objects in a Guice or Gin module are not needed any more: is there a simple way to detect this?

For example, let's say I defined a Provider method for a type with a certain annotation:

@Provides @Named("string range")
String getStringRange(Request foo) {
    return foo.getBarProperty();
}

...only at some point this no longer needs to be injected anywhere and is forgotten to be removed from the module. Is there any way to auto-detect dead code in these Guice modules?

---

Update: Since the only answer so far basically says "look manually" (though the Grapher idea is helpful for manual inspection), I'm adding a bounty to see if there is really is no way at all to auto-detect dead code in guice or gin modules.

Answer 1

You could try using the Grapher in order to visualize the injection graph. This isn't the best as there will still be some manual inspection required to remove "old bindings".

I suppose it would useful to have some sort of "provider scanner" that would inform the user in some way about "unused providers". I'm not aware of any extension that can do this, but such an addition would be helpful.

Answer 2

I was looking around for something like this as well, and i found https://dcd.dev.java.net/. It appears to be very good for Java classes, and as i'm not too familiar with Guice/Gin i don't know if it will be good for you.

Hope this helps

Answer 3

The usual answer is a static code analyzer that understands not only your programming language but also architectural assumptions about your framework, e.g, what it means to be "unused".

I can't speak for the Guice/Gin framework; however, for a longer SO discussion on how to find dead code see http://stackoverflow.com/questions/3883484/using-python-code-coverage-tool-for-understanding-and-pruning-back-source-code-of/3886403#3886403

That solution has to take into account the purpose of the annotations you are using (one of them might say, "keep me around in case a future dynamically loaded class needs to invoke me indirectly"). That adds somewhat to complexity of the answer but doesn't change the basic solution.

This means there isn't an "easy" solution, unless somebody specifically built a tool to do this and makes it available.