Skip to content
This repository has been archived by the owner on Mar 11, 2024. It is now read-only.

deadcode4j v1.5: False Positives

Sebastian Kirsch edited this page Jun 26, 2014 · 2 revisions

deadcode4j neither knows each and every framework nor does it recognize all corner cases of those frameworks it supports. That said, classes reported as being dead may not necessarily be dead. So, don't delete blindly, but double-check the results. Known caveats are:

  • deadcode4j does not consider test code, so classes used in tests only are deemed to be dead (this is a hint to move such classes to the test src)
  • Java reflection. There's no cure for that.
  • Classes with a main method are not recognized as dead code - the reason being that legacy code tends to have test routines defined in the the main method. You may ignore those, have a look at the configuration section below.
  • As the Java compiler inlines constant expressions, class references may not exist in bytecode; this can be circumvented as outlined at stackoverflow
  • The Java compiler also does something called type erasure, thus a class defining a field private List<Foo> = new List<>(); does not depend on the class Foo on bytecode level - which is the basis of deadcode4j's dependency analysis
  • Finally, if the analyzed project isn't closed but represents more of a public API or library, expect deadcode4j to report many classes which are indeed used by other projects

If you know of any other false positives, please report an issue.

In general, I recommend using ack to manually double-check if a class is really dead.
Also, inspecting the implemented interfaces, the superclasses and annotations of a supposedly dead class should be done before finally dumping the code.