01Ground rule
What makes something an example of debt, not just old code?
Debt has interest. An item counts when it makes the next change slower, riskier or impossible, and when you can show that with a measurement. A twenty-year-old class that works and never changes is not debt. A two-year-old class that nobody dares touch is.
That test keeps the list honest. For how to score and order what you find, see technical debt reduction. This page is the catalog of what to look for.
02The catalog
Seven examples and the check for each
| Example | What it looks like | How it is measured |
|---|---|---|
| Framework versions several majors behind | A Spring, Struts or JSF line that no longer gets fixes, with libraries pinned to match | Dependency tree from the build; compare each version to the vendor's supported releases |
| javax namespace imports | Thousands of imports of javax.servlet, javax.persistence and similar that block Jakarta-based releases | Count files containing javax imports; list the libraries that still need them |
| Untested modules | Business logic with no automated tests, or tests that fail and are ignored | Coverage report per module (for example JaCoCo) and the pass rate of the suite |
| Hard-coded configuration | URLs, hostnames, credentials or file paths inside source or inside the packaged archive | Search for IP patterns, connection strings and absolute paths; list what changes between environments by hand |
| Application server lock-in | Vendor descriptors, vendor classes and JNDI names that exist on a single server | Search for vendor package imports and descriptor files; count the modules that cannot start on a plain servlet container |
| Unpatchable vulnerable libraries | A library with a known flaw that cannot be upgraded because another component pins it | Software composition analysis; for each finding, record what blocks the upgrade |
| Release friction | Manual deploys, a build that runs on one laptop, environments that drift | Time and steps from merge to production; number of people who can do it |
03Example in detail
How do you measure javax debt?
Count the files that import from the javax namespace, then separate the packages that moved to Jakarta (servlet, persistence, validation, and others) from the ones that did not (the JDK's own javax packages stay). The first number is the size of the move. The second list is the dependency work: each library that has no Jakarta release is a blocker.
A deterministic recipe can rewrite the imports, so the count is rarely the hard part. The libraries are. See javax to Jakarta migration for how that move runs.
04Example in detail
How do you measure missing tests?
Line coverage is a weak number alone, since a test can execute a line without checking anything. Use three figures per module: coverage, how many tests assert on results, and whether the suite passes on a clean checkout. A module at 70 percent coverage with a failing suite is worse than one at 40 percent that is green.
Where coverage is missing, the fix is characterization tests that record what the code does today. We cover that in legacy code refactoring.
05Example in detail
How do you measure application server lock-in?
Search the code and descriptors for vendor-specific packages, proprietary deployment descriptors and lookups of JNDI names that the server alone defines. Group the hits by module. A module with no hits can move to a plain container as is. A module with hits is a work item, and the count gives its size.
Lock-in counts as debt when you intend to move or the license cost matters. Record it either way. If a move is planned, the WebLogic and WebSphere pages show what the exit involves.
06Limits
What looks like debt but usually is not?
- Old code that is stable, tested and rarely changed. The interest is near zero.
- Style disagreements, naming and formatting. Worth a linter, not a project.
- An internal tool with a retirement date. Record it and accept the cost.
- A design you would not choose today but that meets its load and changes easily.
07Pending proof
What will a real inventory look like?
08How Ace8 helps
From examples to a ranked list
Ace8 is the AI-assisted application modernization practice of AceMQ.
The fixed-price modernization assessment runs these checks across your applications, scores them on one scale and returns a payoff order you own. To fix the items, start with technical debt reduction.