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.
- One App, Every Proxy Case: Where Your CDI Proxies Actually Come From A normal-scoped bean is never handed out directly — a generated subclass is. Where it comes from depends on one thing only, the origin of the type being proxied: your own code, a modular dependency, a jar with no module-info, or a build with no class loader to help it. One example application carries all four cases, and this walks through each — what is generated as source, what as bytecode, and why.
- Vidocq Runtime Is Jakarta EE Core Profile 11 Certified The Jakarta EE Specification Committee has approved our compatibility certification request — Vidocq Runtime 0.3.0 is now a certified Jakarta EE Core Profile 11 compatible implementation.
- I Let My Mac Code All by Itself for Two Weeks Can a local LLM, cut off from the internet, seriously contribute to implementing Jakarta Persistence? A field report — the wins, the derailments, and the thirteen-agent workshop it took to make it work.
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