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.
- The Advisory We Were Watching For: OpenTelemetry's tracestate DoS In September we wrote that the OpenTelemetry API was one of the few third-party artifacts we ship, and the one we watch advisories for. On October 29 that watch paid off. Here is what GHSA-ccrj-gw8r-854m meant for Vidocq, what we measured, and what the upgrade took.
- Vidocq 0.4.0-RC1 Is Out: Servlet 6.1, Pages, MicroProfile 7.2 and a Better Development Loop The first release candidate of 0.4.0 puts eighteen families on Maven Central: Jakarta Servlet 6.1 through Foy, two new bricks (Pages and Expression Language), MicroProfile 7.2, a CLI and a Maven plugin that are one tool, a dev console, new TCK figures and the first SonarQube numbers.
- Vaadin on Vidocq: from vidocq:dev to a 68 MB jlink Image Vaadin Flow now runs on Vidocq and Foy, our Servlet 6.1 container, with no workaround class: in development, as a packaged distribution, and as a self-contained jlink image. Here is how to set it up, what each way of running it gives you, and what we had to fix on the way, since a framework built for the class path met a runtime built for Java modules.
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