This page collects the API mappings and the typical pitfalls when migrating an existing HTTP service to Chappe. For comparative performance numbers, see lien:https://codeberg.org/Vidocq/chappe/blob/main/BENCH.md[BENCH.md].
|
Chappe is at |
From Jetty
| Jetty | Chappe | Note |
|---|---|---|
|
|
Tighter API; no separate connector. |
|
Foy on Chappe |
Servlet via the Foy bridge. |
|
|
No platform pool; no tuning. |
|
|
Simpler model, no |
|
|
|
|
|
Auto-skip on |
From Netty
| Netty | Chappe | Note |
|---|---|---|
|
Virtual threads |
No application-side event loop. |
|
No direct equivalent |
Compose via |
|
|
Synchronous model — Loom makes it scalable. |
|
|
No buffer pool exposed to user code. The |
|
Built-in |
HTTP/1.1 and HTTP/2 parsing live in |
|
Migrating a complex Netty pipeline (for example a multi-protocol proxy with custom backpressure) is a real project. Chappe does not match Netty’s low-level extensibility at the channel layer. If you write your own binary protocol or need fine-grained write-side backpressure control, Chappe is probably not the right tool. |
From Undertow
| Undertow | Chappe | Note |
|---|---|---|
|
|
Equivalent API. |
|
|
Fluent API, same verbs. |
|
|
Native filesystem → classpath fallback chain. |
|
Not needed |
All Chappe handlers are synchronous blocking on a virtual thread. |
|
Virtual threads |
No pool tuning. |
|
Internal headers |
Zero-allocation |
From JDK 25 HttpServer
com.sun.net.httpserver.HttpServer is minimal and not designed for production. Pros: no dependency. Cons: no HTTP/2, no virtual threads by default, limited multiplexing.
| JDK HttpServer | Chappe | Note |
|---|---|---|
|
|
Fluent builder. |
|
|
Match by method + path, not just by prefix. |
|
|
Pure function; no direct socket access. |
|
Default |
No setup needed. |
Switching to the standalone CLI
If your need is just "serve a static site in production" (Docker case), swap your Java launcher for chappe serve:
java \
-jar chappe-cli/target/chappe-cli-*-shaded.jar \
serve --root /var/www/site --port 8080 --gzip
Configuration via YAML, environment-conditional headers, build-time .gz sidecars through the Maven plugin. See Reference — chappe serve CLI.
Typical migration switch points
| Existing feature | Chappe replacement |
|---|---|
HTTP access logger (Tomcat, Jetty |
Custom |
Brotli runtime compression |
Not supported. |
WebSocket |
Planned — see lien:https://codeberg.org/Vidocq/chappe/blob/main/BUG.md[BUG.md]. |
Full Servlet API |
Foy on Chappe (Jakarta Servlet 6.1). |
JAX-RS / REST |
Cassini on Chappe (Jakarta REST 4.0). |
Native PEM TLS loading |
Not supported on the Chappe side. Convert to PKCS12 via |
Migration-ready capabilities
-
Standalone CLI (
chappe serve --config …) — direct Docker packaging, ~50 MB jlink image. -
Filter.gzip()+StaticFileHandler.preferPrecompressed(true)— negotiated compression +.br/.gzsidecars. -
StaticFileHandler.spaFallback("/index.html")/.notFoundFile("/404.html")— SPA routing and custom 404. -
Filter.addHeaderIfEnv("STAGING", "true", "X-Robots-Tag", "noindex, nofollow")— environment-conditional headers. -
Router.mount(prefix, handler)— Servlet/REST extensions composed without coupling.