Code Inventory®: Remove Unused and Dead Code for Easier Maintenance

Code Inventory® is a new feature of the Azul JVM that helps development teams reduce the amount of code they maintain. It is the only solution that precisely catalogs the source code used in production by Java applications, making it easy to accurately identify dead code for removal.

By collecting detailed information from inside the JVM – at the class/package and method level – without the performance penalty of traditional profilers, Code Inventory® provides a comprehensive view across your enterprise’s Java workloads of what code runs over time. It gives an accurate treasure map to dead code so your engineering teams can confidently remove dead code.

Unused or dead code doesn’t impact application performance, so what’s the big deal? It’s important because developers are people, and they lose precious time every time they have to work around expired code or try to figure out what stray code does. One day far in the future when AI is writing all our code, developers won’t care and I’ll be out of a job; but until then, they would rather not be bogged down by this dead weight.

It might seem trivial. How much time can it take to scroll past irrelevant code or otherwise work around it?

Let’s suppose every time a developer works around dead code it takes her 30 seconds, and she has to do this four times an hour. That’s two minutes an hour, which is 16 minutes over an eight-hour day. Research shows that it takes around 23 minutes to become fully engaged in work again after a distraction.

Besides lost productivity, dead code can lead to frustration, low morale, and employee churn.

Why aren’t teams removing unused and dead code

No one seeks to add dead code, but development project increments are called sprints for a reason. Over time we all change methods, comment out annotations, or just generally refactor code in a way that bypasses certain classes or methods. While time spent scrolling through and thinking about these functions can be low, it dramatically increases when teams need to update libraries or upgrade major Java versions. This is when teams actively engage the otherwise dead code to fix compilation errors or test failures that yields no benefit because the code never runs in production.

At successful companies, applications and features grow larger year after year, and the size and complexity of each project increases over time. Teams spend time writing new code but rarely get rid of older code. Developers often don’t remove old code because it’s too risky: what if something called this Java function, and it wasn’t there?

Analyzing for dead code elimination is a time-consuming, boring, soul-crushing activity. No offense if this is your job. Rather than forcing teams to do this, Azul Code Inventory® centralizes collection of first-method execution to pinpoint code that doesn’t run in production. Code Inventory® provides a treasure map for removal.

Some teams do deal with dead code through several techniques. One is static dead code analysis that works to identify unreachable code. If a method is private, then it can only be called through its class. If there’s no call, the method is probably dead. While this works, it’s only based on reachability: if the method is public, it theoretically could be called, or if the entire class is unused…

How Code Inventory® works

Code Inventory® identifies code down to the method level and presents a fully accurate record of code that has run in production during the time span that engineers identify, and of code in production that has not run during that time. It eliminates time searching for and analyzing the codebase. Now they just have to compare code to the Code Inventory® record, and they can use it like a treasure map to find code confirmed eligible for deletion.

1. The application runs on top of the Azul JVM, enabled with Code Inventory® 

2. Data goes through the Forwarder to a point of collection 

3. Each customer’s tenant collects and aggregates the data, marking the first-seen and last-seen date and time of each method to provide visibility across runs. 

4. Application owners can call Code Inventory® for the results via the REST API and compare against their code to plan removal 

Where should I use Code Inventory®?

The best location to collect Code Inventory® data is from production systems: not from dev or test environments. With a over a decade of TDD/Test-Driven Development in the industry, some otherwise dead code is kept alive only because of unit tests. This makes development more difficult because removing the dead code causes an unnecessary and in fact misleading alert of a test failure. The reality though, is that teams can also remove this unit test along with the code.

The production performance impact of Code Inventory® is negligible because of how the JVM operates. The feature has repurposed the JVM’s “first call” features to make a record of what is being called and where that method is. This only happens once per JVM execution, asynchronous to program execution.

Measure your own code

Code Inventory®, a feature of Azul Vulnerability Detection, is generally available to all Azul JVM users running JVMs from April 2023 or later. Please contact Azul to set up your cloud tenant that will collect inventory data and we can assist you in turning it on.