Runtime X-Ray

A test bench: how far can one get with dynamic analysis of Java code by assembling existing free tools? The pages below are the result.

1It slots into a run You hand it the command and it launches it as it is: --java "java -jar my-app.jar". Nothing to change in the code nor in the build — the observers come in through JAVA_TOOL_OPTIONS, which every JVM reads at start-up. On a JVM one does not launch oneself (service, container), --print-options hands over the line to paste.
2Three tools observe JaCoCo records the lines executed, async-profiler measures the time, Arthas captures the values received. Each produces its own report, in its own format.
3Their outputs are brought together The three reports are aggregated into a single view: one page to read rather than three formats to reconcile oneself.

What follows comes from real runs: a travel-time calculator (27 classes, 9 packages, plus one dependency analysed from its jar), under Java 25. Every page below is a tool's output, not a screenshot.

See the demo Three real runs of the same program, in a single report. On the left, all the code that ran, from the costliest to the least. One click opens the method: lines executed in green, never reached in red, the calls leaving each line with their duration, and at the bottom the values received — call by call. A selector moves from one run to the next.

Each tool's raw output

What the view aggregates, in each tool's native format. JaCoCo · async-profiler · Arthas

Coverage, cleaned-up view

The same report as opposite, restricted to the classes actually executed: code never reached is removed, one browses only what was used.

Full coverage

All the code, executed or not. Source annotated line by line: green executed, rouge jamais atteint, jaune branche partiellement couverte.

Inverted profile

The graph turned upside down: one starts from a costly method and walks back to those that call it. That is the question the classic graph does not answer.

Flame graph

A bar's width is the time spent beneath it. Clicking zooms on a branch, typing searches for a method.

Argument values

The values actually received, call by call: @Mode[CAR] @Weather[SUNNY], and what the method returned. This is precisely what neither the coverage nor the profile can give.
The file's last line — "Command execution times exceed limit" — is not an error: it says the requested number of calls was reached and that collection stops.

The tree of ONE call

The path a single invocation really took, with the line numbers — enough to go straight back into the source. Where the profile, for its part, aggregates.
Same remark about the last line: it is collection ending normally, not a failure.

None of these three tools answers on its own. Coverage ignores time and values; the profile samples, so it never proves that some code did not run; inspecting values looks at one named method only. It is their combination that answers — and that is what the aggregated view assembles.

Running it on your own project

Manual ↗

A single file, launched by the java already there: no constraint on how the application starts, no licence, and no connection while it runs. Settings, configuration file, publishing the result.

The repository ↗

The tool's code, the demonstration application, and the evaluation of the eighteen tools compared before arriving at this combination.