Vauban is a CDI 4.1 container that resolves injection at compile time. Native Java Modules, zero runtime dependency, no dynamic proxies — dependency wiring computed like artillery trajectories: drawn on paper before the first shovel of dirt is turned.

Origin of the name

Sébastien Le Prestre, marquis de Vauban (1633-1707), Marshal of France, military engineer to Louis XIV. Designer of the ceinture de fer, author of the Treatise on the Attack and Defence of Fortresses. See the Wikipedia article.

Vauban turned defence into a mathematical art: trajectories, sapping, counter-mining, all computed in advance. The Vauban container brings the same discipline to CDI. Every @Inject relationship is resolved at process-classes. An Indexer enumerates beans, a Processor emits _Factory bytecode via the Class-File API. At runtime, nothing is computed — only instantiation remains. The fortifications stand before the first request hits.

At a glance

Implemented spec

Jakarta CDI 4.1 — Lite profile

Repo

https://codefloe.com/Vidocq/vauban

Java

25 (LTS)

Java modules

io.vidocq.vauban.api, io.vidocq.vauban.core, io.vidocq.vauban.indexer, io.vidocq.vauban.processor, io.vidocq.vauban.junit, io.vidocq.vauban.classloader.spi, io.vidocq.vauban.classloader, io.vidocq.vauban.weaver, io.vidocq.vauban.sjar

Runtime dependencies

Spec APIs only: jakarta.cdi, jakarta.cdi.lang.model and jakarta.el — vauban-core also requires the JDK’s jdk.unsupported module

CDI 4.1 Lite TCK

774/774 — see detailed status

Three identifying traits

  1. Zero runtime dependency — Jakarta CDI spec only. No Weld, no ArC, no Guice. The rule covers what Vauban ships: every published library depends on the Jakarta APIs it implements and on nothing else. Build-time tooling is held to a different standard — a Maven plugin runs on the build machine, never in your application, so it may take a dependency when that saves writing something better done elsewhere. Each one is named in the reference.

  2. Static code generation — the annotation processor and the Class-File API (JEP 484), at build time. Beans are instantiated, injected and proxied by generated code living in your own packages: no bytecode generated at run time, no reflective access that needs an opens, no external bytecode library (ASM, Byte Buddy). What still reflects is listed under AOT compatibility.

  3. Strict Java Modules — every Vauban artefact has its own module-info.java. No classpath, no unjustified opens, no add-opens at launch.

Position in the ecosystem

Diagram