Vidocq Documentation
Version

Vidocq Runtime is at 0.4.0-SNAPSHOT. Any real-world migration is premature — this page documents the mappings ahead of time.

Side-by-side comparison

Aspect Vidocq Runtime Quarkus Helidon MP Spring Boot Open Liberty Payara Micro

Minimum JDK

25

17

21

17

17

17

I/O threading model

Virtual threads

Vert.x event loop

Helidon Níma (VT)

Tomcat / Netty

Platform threads

Platform threads

Build-time vs runtime

Build-time (Class-File API)

Build-time (Gizmo / ASM)

Runtime

Runtime

Runtime

Runtime

Strict Java Modules

Yes

No

No

No

No

No

Native AOT

GraalVM + Leyden CDS

GraalVM

GraalVM

GraalVM

Partial

Partial

Typical cold start (jlink/CDS)

~1 s

~0.5 s (native)

~1 s

~3 s

~5 s

~3 s

Standalone image size

~40 MB (jlink)

~80 MB (native)

~50 MB

~70 MB

~150 MB

~80 MB

ASM / Byte Buddy dependency

None

ASM (Gizmo)

ASM

ByteBuddy + ASM

ASM

ASM

The numbers above are indicative and will be updated as BENCH.md runs land. See the workspace root BENCH.md for exact measurements.

From Quarkus

Vidocq Runtime explicitly borrows the Quarkus extension pattern.

Quarkus Vidocq Runtime Note

Quarkus deployment build steps + recorders (io.quarkus.deployment)

io.vidocq.runtime.spi.VidocqExtension lifecycle (configure / beforeStart / onStart / onStop)

Simpler model — ServiceLoader discovery, ordered by priority(), no build-step graph

Gizmo bytecode generation (ASM)

APT + Class-File API (JEP 484) at compile time

No ASM — standard JDK bytecode

ArC (runtime CDI)

Vauban

Build-time in both cases

RESTEasy Reactive

Cassini on Chappe

No Vert.x — virtual threads

Hibernate Reactive / ORM

Mansart

JDBC + virtual threads, no Vert.x SQL Client

Jackson

Champollion

JSON-B 3.0 / JSON-P 2.1 implementation

The forthcoming compare-to/ workspace examples will illustrate migrating a simple extension.

From Helidon MP

  • Helidon SE (Web) → Chappe + Cassini.

  • Helidon MP → Vidocq Runtime directly.

  • application.yaml → MicroProfile Config (vidocq.properties or env).

  • Helidon Níma already uses virtual threads — the transition is conceptually transparent.

From Spring Boot

Spring Boot does not naturally align with the MicroProfile model, and migration touches the programming model.

Spring Boot Vidocq Runtime Note

@SpringBootApplication

Vidocq.main(args) + any class

No application class required

@RestController

@Path + @GET/@POST

Standard Jakarta REST

@Service, @Component

@ApplicationScoped

CDI Lite

@Autowired

@Inject

Constructor injection preferred

@ConfigurationProperties

@ConfigProperty injection

MicroProfile Config via vidocq-runtime-ravel-config-extension

application.yml

vidocq.properties + MP profiles

%<profile>. prefix

Spring Data JPA

Mansart (Jakarta Data 1.0)

APT-generated repositories

From Open Liberty / WildFly

  • server.xml → MicroProfile Config + Vidocq Runtime extensions.

  • EAR → standalone JAR + Maven plugin.

  • JNDI → CDI lookup via Vauban.bootstrap().

  • Jakarta annotations — directly compatible, the programming model stays identical.

From Payara Micro

Payara Micro and Vidocq Runtime share the MicroProfile target. The main difference is the build-time approach: Payara Micro embeds GlassFish; Vidocq Runtime produces a minimal jlink binary without a classical application server.

  • payara-micro --deploy app.war → bin/run.sh from the vidocq:package bin/ + lib/ distribution (also attached as a -dist.zip).

  • payara-micro.jar (~80 MB) → jlink image (~40 MB).

  • Every enabled MicroProfile feature.xml is replaced by the matching Vidocq Runtime extension.

MicroProfile table

MicroProfile spec Vidocq Runtime status Extension

MP Config 3.1

Delivered

vidocq-runtime-ravel-config-extension

MP Health 4.0

Delivered

vidocq-runtime-knock-health-extension

MP Metrics 5.1

Delivered

vidocq-runtime-dirac-metrics-extension

MP OpenAPI 4.2

Delivered

vidocq-runtime-grimm-openapi-extension (+ vidocq-runtime-grimm-openapi-ui-extension)

MP REST Client 4.0

Delivered

vidocq-runtime-cyrano-rest-client-extension

MP JWT Auth 2.2

Delivered

vidocq-runtime-cervantes-jwt-extension

MP Telemetry 2.2

Delivered

vidocq-runtime-humboldt-telemetry-extension

MP Fault Tolerance 4.1

Delivered

vidocq-runtime-heisenberg-fault-tolerance-extension

Seven extensions run the TCKs of their MicroProfile 7.2 specifications and the Metrics 5.1 extension runs its own TCK (Metrics is not part of the 7.2 platform); all eight pass on the assembled runtime, through the runners embedded in vidocq-runtime-integration-tests (Maven profile tck) — 1888 TCK tests green on 2026-10-04. The OpenAPI 4.2 and Telemetry 2.2 runs use release-candidate TCKs, byte-identical to the finals; the 7.2 platform release is still under ballot. See TCK status.

The dev console is no longer a dependency NEW

Before, an application declared vidocq-runtime-devconsole-extension itself to get the dev console, and that dependency shipped in every binary vidocq:package, jlink, jpackage and docker produced — off by default, but its code was there. mvn vidocq:dev now adds the console itself, at the Vidocq version of the application’s Chappe extension, the moment the application already has vidocq-runtime-chappe-webserver-extension; no application ever needs to declare it, and no binary ever contains it (Vidocq/vidocq#143).

  • Remove vidocq-runtime-devconsole-extension from the pom. vidocq:checkpom already warns about it if you do not — a dev-only dependency declared outside test scope — and every packaging goal drops it anyway, with a warning, whether or not you remove it. Its SPI, vidocq-runtime-devconsole-spi, a small API jar, stays in the binary as long as the console, or an extension that requires the SPI, is declared.

  • Unless a test reads the console, such as one that calls its /api/snapshot: keep the dependency, moved to <scope>test</scope>, together with the -dev module of any extension whose live panel the same test reads (A -dev module, never packaged). test scope is never packaged, and checkpom accepts it.

  • An application that got vidocq-runtime-chappe-webserver-extension only transitively through the console — the console depends on it, so declaring the console was enough to bring Chappe along — now declares Chappe itself. Without it, vidocq:dev logs Dev tools: no dev console, it needs vidocq-runtime-chappe-webserver-extension and starts without one, since nothing serves the console’s page any more.

See Dev tools and binaries for the whole picture, including the six -dev panel modules this repository’s own extensions now ship.

Config and Rest Client need their codegen bundle NEW

Two extensions now ship a -codegen bundle, as the others already did, and vidocq:checkpom fails the build of an application that declares the extension without it:

  • vidocq-runtime-ravel-config-extension → vidocq-runtime-ravel-config-extension-codegen (Vidocq/ravel#21). Without it, @Inject @ConfigProperty was reported unsatisfied at compile time, and the only way out was -Avauban.validation=false.

  • vidocq-runtime-cyrano-rest-client-extension → vidocq-runtime-cyrano-rest-client-extension-codegen (Vidocq/vidocq#207). Without it, @Inject @RestClient was unsatisfied at boot.

Add each one to the compiler’s annotationProcessorPaths, next to the inherited indexer (combine.children="append"). checkpom prints the <path> to paste:

<path>
    <groupId>io.vidocq.runtime.extensions.microprofile</groupId>
    <artifactId>vidocq-runtime-cyrano-rest-client-extension-codegen</artifactId>
    <version>0.4.0-SNAPSHOT</version>
    <type>pom</type>
</path>

vidocq extension add ravel-config and vidocq extension add cyrano-rest-client write it for you. See the Config extension and the Rest Client extension.

vidocq:modularize is now vauban:modularize NEW

The goal moved to io.vidocq.vauban:vauban-maven-plugin. A pom that runs vidocq:modularize declares the Vauban plugin instead, renames the vidocq.modularize. properties to vauban.modularize., and drops <release>; the copies are written to target/vauban-modularized/, where vidocq:dev, vidocq:jlink and vidocq:package read them. See modularize moved to the Vauban plugin.

Next steps