Jakarta EE · MicroProfile · Java 25
Vidocq
Zero external dependencies — zero inherited CVEs. Strict JPMS module isolation closes the door on reflection attacks and classpath pollution, making Vidocq the first Java framework that is jlink- and jpackage-ready out of the box.
Six constraints. One runtime.
Every design decision in the Vidocq ecosystem flows from the same set of rules, applied consistently across all fifteen projects.
JPMS-native
Every module ships a module-info.java. Minimal exports, no unjustified opens, no classpath fallback, no split packages.
Virtual threads throughout
All I/O paths run on virtual threads. No platform thread pool without a documented reason.
Static code generation
The Class-File API (JEP 484) and APT produce all metadata at compile time. No reflection, no dynamic proxies, no startup scanning.
Zero runtime deps
Production scope: only the Jakarta or MicroProfile spec artifact. No ASM, no Byte Buddy, no utility libraries.
Independent bricks
Fifteen self-contained projects, each with its own release cycle. Consume only the layers you need.
AOT-ready
GraalVM native and Leyden CDS work out of the box — no reflection config, no dynamic proxies to register.
Architecture
Four layers. No circular dependencies.
The dependency graph is strictly layered. Foundational bricks carry no inter-dependency. Jakarta layers compose them. MicroProfile implementations sit on top. The orchestrator wires everything through an extension SPI.
From the blog
Engineering notes, release updates, and implementation deep-dives from the Vidocq ecosystem.
- Launching the Vidocq Site Why we chose Roq and what to expect here.
- Why Vidocq is built as independent bricks The rationale behind fifteen separate release trains.
Get involved
Contributions are welcome at every layer — from TCK coverage to implementing a new MicroProfile specification.
The contributing guide covers prerequisites (Java 25, Maven 4, SDKMAN), JPMS conventions, the zero-deps rule, virtual-thread patterns, and the PR workflow.
Contributing guide