MicroProfile · Java 25 · AI-augmented development · 100% European
Vidocq
A 100% sovereign European stack — zero external dependencies, zero inherited CVEs, full technological independence. 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.
Innovations
Beyond the core constraints, Vidocq ships capabilities you will not find in any other Java runtime.
Secured JARs (.sjar)
JPMS archives encrypted with AES-256. The exposed surface — public API and SPI packages — stays in the clear so consumers compile and link normally; everything else is ciphered at rest, protecting your intellectual property and shrinking the attack surface.
JAR enrichment plugins
Vauban and Vidocq plugins can enrich external JARs — adding CDI metadata, indexes, and generated glue to third-party libraries that were never built for the ecosystem, without touching their source.
Hot reload
A first-class hot-reload mode reflects code and configuration changes live, keeping the inner development loop tight without restarting the runtime.
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.
The people behind Vidocq
Vidocq was initiated by two long-time members of the Java, Jakarta EE and MicroProfile communities.
From the blog
Engineering notes, release updates, and implementation deep-dives from the Vidocq ecosystem.
- No More Parent Needed: a Vidocq Application Is a BOM, a Plugin and Its Dependencies In the 0.4.0 line, 0.4.0-SNAPSHOT today, a Vidocq application no longer has to inherit vidocq-runtime-parent: the Maven plugin, loaded as a build extension, gives the build everything the parent used to carry. Your company parent stays yours, the pom shrinks, and the CLI converts in both directions.
- Vidocq 0.4.0-RC2 is available, and it's fast ;) The second release candidate of 0.4.0 is on Maven Central: 80,000 requests per second with a p99 under 9 ms, a start in under a second, 127 MB at rest, restores from a CRaC snapshot in about 400 ms, and a CLI that takes you from an empty directory to a Docker image without you writing a single opens line.
- Checkpoint, Restore, Answer: Vidocq on CRaC Vidocq can now be snapshotted warm and restored in a fresh container with CRaC. Only one optional module knows about CRaC; every other brick implements a small neutral interface, with no reflection, and the application takes part through two CDI events. Here is how it works, how to try it, what a snapshot does not carry, and the first numbers: a restore in about 400 ms, whatever the start-up took.
Get involved
Contributions are welcome at every layer — from TCK coverage to implementing a new MicroProfile specification.
The contributing guide shows where to start (the Vidocq workspace), how to propose a change from your fork, and how contributors become maintainers. It also sums up the engineering rules: Java Modules, zero runtime dependencies, virtual threads.
Contributing guide