This repository has been archived by the owner on Mar 11, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 5
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 themain
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 classFoo
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.