Java That Resolves Real Types
Java is a first-class language in TheAuditor, and the point is how. It resolves real types with the actual Java compiler toolchain instead of matching names, so callsites, overrides, inheritance, routes, and ORM queries bind to actual resolved types.
“Supported” is the lowest bar a language tool can clear. Plenty of scanners parse Java, list it on the box, and then reason about it by matching text. A method named execute might be the dangerous one or a namesake three packages away, and a tool that guesses from the name cannot tell you which. In Java, where behavior hides behind interfaces, overrides, and inheritance, guessing from names is guessing, and guesses are how a scanner both misses real bugs and cries wolf on safe code.
Java was the headline language work of this cycle, and the work went into not guessing.
Name-matching guesses, resolution knows
Java findings are now grounded in real type resolution. The engine runs the actual Java compiler toolchain over your code and binds to the types it resolves, not to the strings it sees. A call resolves to the method it actually dispatches to. An override resolves to the concrete implementation that runs. Inheritance is followed to where behavior really lives. Web routes bind to the handlers that serve them, and ORM queries bind to the entities and columns they actually touch. When the engine says a value reaches a query, it is because the resolved types say so, not because two identifiers happened to share a name.
That is the difference between a heuristic and a fact. A heuristic is right often enough to demo. A fact is what you want under a finding you are about to act on.
Two views, reconciled, with a check that will not proceed on drift
The engine builds two views of your Java: a structural view of how the code is written, and a semantic view grounded in real type resolution and symbol binding. Those two views have to agree. If they drift apart, the safe move is not to pick one and ship a finding built on a mismatch. It is to stop.
So a hard fidelity check reconciles the two, and it refuses to proceed when they disagree. A finding is only produced when both views of the code line up. This is the same discipline we hold everywhere in the engine: a result built on an internal disagreement is not a result, it is a bug waiting to be reported as a vulnerability.
Why this was worth the cost
Real type resolution is more expensive than matching names. We paid for it because Java is where the expensive path pays off. Enterprise Java leans on exactly the indirection that name-matching handles worst: dependency injection, deep class hierarchies, framework-driven routing, and ORM-mediated data access. Grounding the analysis in resolved types is what lets a finding in a large Java service mean what it says.
Honest scope note
Real type resolution needs to see your code the way a compiler does. Where a project will not resolve, the engine reports that as a gap rather than silently falling back to guesswork and calling it coverage. Consistent depth across languages is a direction we hold to a standard, not a claim that every construct in every framework is modeled today. What we will not do is put Java on the box and back it with name-matching underneath.
Where this sits
Java joins the other lanes held to one standard and measured against an independent yardstick at BenchProctor. TheAuditor is the ground-truth layer for Code Reality Labs. It is in final commercial release preparation and ships when its hardening checks pass. Subscribe on the main site for launch news.
Was this useful?