Fluxtion code-gen at a glance

Fluxtion has two independent axes: how you author the topology (left to right) and when / how the code-gen runs (top to bottom). Any cell produces the same artifact — a deterministic dispatcher you can audit, replay, and ship.

Generation mode	Imperative Java	DSL fluent	Spring XML	Vendor JAR
Gen 1 — In-process compile Compile at startup, run, throw away the source.	Generation 1	Hello world (DSL)	Spring — in-process	composes with the others
Gen 2 — In-process interpreted No code generation — walks the topology graph reflectively. CheerpJ-friendly fallback.	Generation 2	not yet exercised	not yet exercised	not yet exercised
Gen 3 — In-process compile + source Compile, keep the source for inspection, run.	Generation 3	every DSL example with source view	Spring — in-process	composes with the others
Gen 4 — AOT, user-invoked Main is the build tool — Fluxtion.compile() writes .java to disk.	Generation 4	not yet exercised	not yet exercised	not yet exercised
Gen 5/6 — AOT, tool invoker FluxtionGraphBuilder convention — a build tool runs every builder in the project.	Generation 5 (single)	not yet exercised	Spring — AOT	Spring — 3rd party
Gen 7 — compileDispatcher live-binding Generated dispatcher binds your live node instances at runtime.	Generation 7	not yet exercised	not yet exercised	not yet exercised

Authoring channels — the columns

Imperative Java

cfg.addNode(new Node()) from a Main method or a FluxtionGraphBuilder. Lowest abstraction, highest control. Most Generation-section examples live here.

DSL fluent

DataFlowBuilder.subscribe(...) + .map/.filter/.sink. Stream-shaped topology. Hello world (DSL), most Connecting data examples, the Fluxtion DSL section.

Spring XML

Beans become nodes. Useful when another team / tool authors the topology, or when you want the integration boundary visible outside Java. See the Spring builder section.

Vendor JAR

A library ships pre-built Fluxtion nodes. Consumer names entry-point beans in XML; substrate walks field references to materialise the rest of the subgraph. Full story: Vendor libraries.

Generation modes — the rows

The seven rungs are a teaching arc, not a feature list — each rung shows a specific cost / visibility / lifecycle trade-off. Walk them in order in the Fluxtion generation section of the playground.

Gen 1 / 2 / 3 — run inside one JVM. Fast iteration, source either thrown away (1), absent (2), or kept for inspection (3).
Gen 4 — Main writes the AOT artifact to disk; deployment JVM loads it via Class.forName. The "build my own deployment jar" path.
Gen 5 / 6 — a build tool runs every FluxtionGraphBuilder it finds. The canonical Maven/Gradle integration shape.
Gen 7 — generated dispatcher binds your live node instances at runtime (compileDispatcher). When the user's outer code needs to hold references to nodes after compile.

Why the matrix matters

Every cell in the table produces the same deliverable: a generated .java + .class + .graphml describing one deterministic dispatcher. The authoring channel decides who writes the topology; the generation mode decides who runs the compile. The artifact is what your auditor reviews, what you ship, and what downstream systems ( mongoose for physical deployment) consume.

That orthogonality is the product story. Many cells are still not yet exercised — they aren't blocked by the substrate, just by example-writing capacity. Patches welcome.

Where to start

Open the playground and try one row from each interesting column. Then read the generated .java — that's what the rest of the story builds on.