Vidocq Documentation

Vauban is a CDI 4.1 container that resolves injection at compile time. JPMS-native, 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://codeberg.org/Vidocq/vauban

Java

25 (LTS)

JPMS 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.sjar

Runtime dependencies

None beyond jakarta.cdi and jakarta.cdi.lang.model

CDI 4.1 Lite TCK

partial — see detailed status

Three identifying traits

  1. Zero runtime dependency — Jakarta CDI spec only. No Weld, no ArC, no Guice.

  2. Static code generation — Class-File API (JEP 484) at process-classes. No reflection at startup. No dynamic proxy. No external bytecode library (ASM, Byte Buddy).

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

Position in the ecosystem

Diagram

Performance numbers live in BENCH.md. None appear inline in this page.