A roundup covering several Quarkus community posts: a benchmarking correction where fixing measurement bias raised Spring's numbers while Quarkus's stayed flat, an investigation into virtual thread pooling advice from OpenJDK, a Project Leyden-based approach to faster JVM startup in containers, a guide to building hardened Quarkus images with Jib and Java 25, and a small extension that prints an application name banner at startup. Also mentions Quarkus Insights episodes and upcoming events.
Questions this post answers
Should I pool virtual threads in Java to improve performance?
OpenJDK's own guidance is not to pool virtual threads, and testing that advice with real data confirmed why: pooling broke performance, and attempts to fix the JVM to compensate made things worse rather than better. Virtual threads are designed to be cheap and disposable, so creating new ones instead of reusing pooled threads aligns with how the JVM schedules them. Developers tuning JVM concurrency can track virtual thread guidance and gotchas like this on daily.dev.
How can I get faster JVM startup times in a containerized Quarkus application without losing diagnostics?
Project Leyden combined with Quarkus offers a deployment option that speeds up container startup while still preserving JVM diagnostics, agent support, and compatibility with existing tooling, giving teams a middle ground between raw JVM startup and more aggressive native-image approaches. Teams weighing JVM startup tradeoffs can follow Quarkus and Project Leyden updates through daily.dev.