Quarkus 4 is coming, and one key decision was raising the Java baseline to 21. This post explains why.Let’s be clear: nothing is wrong with Java 17!Where we are heading as a framework is what really matters.Virtual threads, for real this timeJava 21 is the first LTS with virtual threads. Quarkus 3 already supported them, but through reflection hacks to avoid depending on the Java 21 API (here’s what that looked like). This is hard to maintain, it leads to suboptimal performance, and we need a convoluted fallback. Worse: virtual threads felt like second-class citizens; not every extension was tested with them.All of this changes with Java 21 as the baseline. No reflection, no conditional paths. We can test virtual threads support in each extension easily and catch issues before you do. As an application developer, you keep using simple, blocking APIs, and get the scalability benefits from virtual thread.If you’re an extension writer: expect a much simpler path to support virtual threads.The ecosystem is movingWe’re not early. Projects are already dropping Java 17:Error Prone requires Java 21Jenkins CI no longer supports Java 17Apache Jena 6 requires Java 21Jakarta EE 12 sets Java 21 as the platform baseline. Each spec can decide to stay on 17, but none can go higher than 21. If Quarkus 4 started at 17, we’d need a mid-lifecycle bump to adopt these specs. That’s exactly what we want to avoid.The clock is ticking for Java 17When we started discussing this change, some community members said, "Java 17 is EOL, no-brainer." The reality depends on your JVM vendor; support ends in 2027 or 2029. But Quarkus 4 will be around for several years, which takes it past those 2027 or 2029 dates. We wanted to be ahead of these cut-offs, not chasing them.A leaner build matrixQuarkus currently tests against Java 17, 21, and the next LTS preview. It’s a lot of machine time and a lot of cost. Dropping 17 means two LTS versions instead of three. With Java 29 on the horizon, keeping Java 17 would mean four versions. It’s not a sustainable number of variants.Why not Java 25?Great question. Our usage data still shows strong Java 21 usage. Java 25 has benefits, but Quarkus already supports it, including FFM, without a hard dependency. Native compilation uses Mandrel 25 regardless.What changes for you?Not much. Java 21 usage (blue) is growing; Java 17 (green) is declining. Quarkus 4 is heading where our community already is. The first RC is planned for the end of September.If you’re on 21+, nothing changes. If you’re on 17, now is a good time to plan the move.