graalvm
- Six OOMs and a Connection Pool
A Spring Boot imperative app OOM'd six different ways at 256MB. Each HTTP client swap revealed what was actually eating the heap.
- The numbers lied until we fixed the ports
Same reactive app on Micronaut, Spring Boot, and Quarkus. The numbers lied until we fixed the harness AND the ports.
- -Xmx Won't Save Your Native Image
JAVA_TOOL_OPTIONS is a no-op on a native binary. The 256MB OOM that docker stats couldn't see.
- Quarkus 12,563 vs Spring 820 (Both Numbers Are Wrong)
A Prometheus counter that resets on OOM crash-loops turned a 5x throughput advantage into a 15x deficit. The fix is six lines of awk.
- The Throughput Was Always 115
28 mock APIs. Twelve benchmark scenarios. Two codebases. One number: 115 req/s.
- Designed a Reactive Benchmark. Imperative Won.
Built a reactive benchmark with realistic latency. The imperative rewrite survived memory pressure. Reactive didn't.
- 265 req/s on All Three Runtimes (Until You Add a Memory Limit)
Native image, JVM, and virtual threads all hit 265 req/s. Then the memory limit dropped.
- Error Is Not Exception: Micrometer's Silent CPU Metric on Native Image
The catch block that catches nothing#This code has a bug. Not a typo, not a logic error. A type hierarchy bug. private double invoke(@Nullable Method method) { try { return method != null ? toDouble((Number) method.invoke(operatingSystemBean)) : Double.NaN; } …
- We Removed Reactor. Nothing Got Slower.
We took the entire reactive stack out. R2DBC, Mono, Flux, Reactor Core, loom-carrier, flatMap with its carefully-tuned concurrency arguments. Replaced it with JDBC, HikariCP, and blocking method calls. Same endpoints. Same Netty HTTP server. Same PostgreSQL. …
- Five Things Spring Boot 4.1 Doesn't Tell You Until It's Too Late
Spring Boot 3.5 lost OSS support on June 30, 2026. Boot 4 modularized autoconfiguration, and its silent failures cost an afternoon.