Vidocq est une suite de runtimes Jakarta EE et MicroProfile écrite en Java 25 pur, JPMS-natif, fondée sur la génération de code statique (Class-File API + APT) et les virtual threads.
L’écosystème en un diagramme
Chaque module est un projet indépendant, publié séparément, avec son propre cycle de vie. Vidocq Runtime les assemble via une SPI d’extensions inspirée de Quarkus.
Pourquoi un nouveau runtime ?
Trois raisons :
-
Souveraineté technique. Le monde Jakarta repose largement sur quelques fondations historiques (Tomcat, Jetty, Netty, Hibernate, Yasson, ArC, RESTEasy). Travail remarquable, dépendances accumulées. Vidocq prend le pari de tout réimplémenter sur Java 25 pur, en s’appuyant sur ce que la JDK propose désormais : virtual threads, scoped values, Class-File API, JPMS strict.
-
Génération à la compilation. Pas de réflexion à chaud, pas de proxy dynamique, pas d’ASM, pas de Byte Buddy. Tout ce qu’on peut calculer à
compile-timeest calculé àcompile-time. Au démarrage, on instancie. Compatible AOT (GraalVMnative-image, Project Leyden CDS). -
Inspiration historique sobre. Chaque composant rend hommage à une figure française de la fin XVIIIᵉ / début XIXᵉ siècle dont la méthode résume l’esprit du module. C’est un parti-pris esthétique, pas un pastiche.
Les composants
| Composant | Rôle | Repo |
|---|---|---|
Serveur d’application MicroProfile, orchestrateur d’extensions |
||
Container CDI 4.1 Lite, build-time, JPMS-natif |
||
Implémentation Jakarta REST 4.0 / JAX-RS |
||
Implémentation Jakarta JSON-P 2.1 + JSON-B 3.0 |
||
Serveur HTTP/1.1 + HTTP/2 (HTTP/3 en chantier), virtual threads, zéro dépendance |
||
Implémentation Jakarta Servlet 6.1 |
||
Implémentation MicroProfile Config 3.1 |
||
Implémentation MicroProfile Health 4.0 |
||
Implémentation MicroProfile Metrics 5.1 |
||
Implémentation MicroProfile Fault Tolerance 4.1 |
||
Implémentation MicroProfile JWT 2.1 |
||
Implémentation MicroProfile Rest Client 4.0 |
||
Implémentation MicroProfile Telemetry 2.1 |
||
Implémentation MicroProfile OpenAPI 4.1 |
||
Jakarta Data 1.0 + Jakarta Persistence 3.2 (M7 en attente) |
Pages transverses
-
Architecture globale — frontières des modules, matrice de dépendances, choix transverses (zéro-dépendance, JPMS, codegen, virtual threads).
-
Comparatif — Vidocq Runtime face à Quarkus, Helidon SE 4 et Spring Boot 4.
-
Roadmap consolidée — statut par module et jalons proches (M2x, M5, M6c, M7).
Statut
|
La suite est en 0.1.0-SNAPSHOT. Aucune garantie de stabilité d’API. Aucune release publique. Ne pas utiliser en production. |
Ce qui marche aujourd’hui :
-
Chappe — HTTP/1.1, HTTP/2, virtual threads, conformance RFC 9110/9112/9113.
-
Vauban — CDI 4.1 Lite build-time, plugin Maven, intégration JUnit.
-
Cassini — REST 4.0, intégration TCK partielle (voir
cassini/cassini-migration.md). -
Champollion — JSON-P 2.1 + JSON-B 3.0, génération APT, suites TCK partielles (voir
champollion/JSON-ROADMAP.md). -
Foy — Servlet 6.1, intégration TCK partielle.
-
Vidocq — orchestrateur initial avec extensions Mansart H2 + transactions.
-
MicroProfile — Config (Ravel), Health (Knock), Metrics (Dirac), Fault Tolerance (Heisenberg), JWT (Cervantes), Rest Client (Cyrano), Telemetry (Humboldt), OpenAPI (Grimm), chacun câblé dans Vidocq Runtime via une extension.
Ce qui est en chantier :
-
Mansart — Jakarta Data 1.0 SPI, JPA 3.2 en plan.
-
WebSocket — Chappe + Foy.
-
HTTP/3 / QUIC — Chappe.
-
MicroProfile — durcissement TCK et intégration transverse dans Vidocq Runtime.
Détail complet par module : Roadmap consolidée.
Liens utiles
-
Dépôt : codeberg.org/Vidocq
-
GitHub mirror : (à venir)
-
Matrix / Discord : (à venir)