Trash Pandas Love Enterprise Java Code

If raccoons were software engineers, they would feel at home inside many enterprise systems. These systems are often full of unused and dead code that was written, fully tested, then altered in a way that prevents teams from ever running it.

This garbage code — a raccoon’s favorite — is a maintenance burden that developers must work around to keep passing tests while other major changes are made. This code often doesn’t end up in the trash because it’s hard to know what can be safely removed without breaking the application. But you can better identify bad code if you understand how to look for it.

The typical way to identify dead or unused code is through static analysis or log review. Modern IDEs can detect unused and dead code via reachability analysis, but there is a soundness problem for classes and methods that aren’t 100% private. If the code has a public access modifier, then it could load so your tools will never report it.

Other times when code is tracked, it runs in a unit test — technically, this code is not dead. Unfortunately, while test-driven design is a good practice, there are portions of code that are alive only because a unit test fails when that code is removed. All this testing does is verify that unnecessary baggage fulfills its original design.

Although removing the unused and dead code makes the test go red, developers can also remove this test and speed up the overall build pipeline by not having to run it anymore. The best way to get a full picture of which code can be thrown away is to separately monitor test and production environments and see what happens.

Unused and Dead Code Is Clutter

Many teams have a “why worry” attitude: How much unused and dead code can there actually be, and why does it matter? Unused and dead code is clutter that slows down the present and future. Every time someone works on the application, they have to work around that code. When a major change is made, like upgrading from Java 11 to 17 or 21, all that unnecessary code needs to be maintained. The build pipeline takes time to ensure that the code works, regardless of whether the code matters.

When a major U.S. financial institution set out to identify and remove unused code, it was able to “reduce the size of a codebase by 67%.” The reduced complexity improved developer experience so much that developers released updates to the application over 250 times in a year and finally upgraded some of the older libraries that had held them back.

A similar IEEE study of an industrial software system found that up to 50 percent of a large codebase was unused or dead, and the overall average was 5% to 10% of code was unused or dead. The larger and older an application is, the higher the percentage.

Unused and Dead Code in Java

Java engineers can treat unused and dead code detection similar to garbage collection: Choose your setting and let the JVM do the rest. The question of whether code is used in production is answered by whether the method is ever called (or inlined). The recording of this decision is made in one of three places: the bytecode interpreter, AppCDS (Application Class Data Sharing) or the ReadyNow feature of Azul Platform Prime. If the method is used again, there’s no need to affect performance beyond recording the first call. The method was used in production, so the code is not unused or dead. In this scenario, JVM runs are tagged with the “application environment” to help record which application called the method for a given environment. Keeping these environments separate helps identify cases where the code and unit tests only serve to keep each other alive.

Monitoring code to see what you can throw away requires the added dimension of time. Until you’ve watched the application for a bit, plenty of the code hasn’t run. Here teams often separate dead code into two parts: things they think they can get rid of but just aren’t sure about, and things that need a longer time to see — often based on some type of periodic activity associated with the business cycle.

Developers may be suspicious that certain parts of the code are unused or dead, but not confident enough to delete it. The path would be to track code inventory, perform some actions in the application and see if those methods were reported as running. If they were, then the code is live; if not, it’s probably unused or dead. Other functionality, like a year-end report, needs to run its course to do detection. This is why monitoring the live-ness of code is best done over time. The short victories can be won early, then more code can be tossed aside later.

Code Inventory Reduces Code Clutter

Azul’s Code Inventory differs from typical static analysis tools and IDEs that detect unreachable code. The monitoring from Code Inventory occurs from the running JVM to identify entire classes or public methods that are present but don’t run. It’s a clutter finder — a raccoon repellant. It accurately identifies unused and dead code for removal by precisely detailing what custom and third-party code is running.

Dead code detection improves developer productivity and developer happiness. It’s a burdensome chore to maintain code whose sole purpose is to satisfy a test that ensures that the unnecessary code works. By detecting unused and dead code, developers can safely throw it into the trash — a tasty treat for our raccoon friends.