Analyzer::Java::HelidonSe
Inherits Analyzer < FileHelper < Reference < Object
Helidon SE's routing table is composed two ways at once: inline verb
calls directly on a HttpRouting.Builder/HttpRules, and modular
HttpService classes mounted elsewhere via
builder.register("/prefix", new SomeService()). The second shape —
one HttpService per resource, wired up from a separate Main
class — is what every Helidon-published quickstart/example uses, so
getting only the first shape right would miss the prefix on nearly
every real route.
TreeSitterHelidonSeExtractor reports the two shapes per file:
verb calls tagged by their enclosing class, and .register(...)
edges tagged by (enclosing class, target class). This analyzer
aggregates both across every Helidon-marked file in a project root
and resolves the resulting mount graph — classes are matched by
simple name, root-scoped, the same approximation the JAX-RS
analyzer's bean/subresource indices and the Micronaut analyzer's
interface-route index already make for cross-file linkage.
Constants
io.helidon.webserver covers the HttpRouting/HttpService/
HttpRules/WebServer types across Helidon 2.x-4.x — a class
that implements HttpService or builds a HttpRouting.Builder
necessarily imports (or fully-qualifies) something under this
package, so a single substring check is a genuine positive
signal rather than "any Java file with .get(...) calls".
Class methods
Instance methods
Instance-side view of the same declaration. The per-file rescues live on
this base class, which has no way to name the analyzer that is running
inside them, so a skipped file could not be attributed to a tech.
Deriving it from analyzer_for keeps the name written exactly once.