Java is not glamorous in 2026. It is also not going anywhere. If anything, the language and runtime are in the best shape they've been in for a decade — virtual threads, pattern matching, records, and a JIT that consistently outperforms most alternatives on long-running workloads. The question is no longer "Java or not Java" but "which Java framework, and why."
The frameworks that matter
Spring Boot
Still the default. Still the right call for the majority of enterprise Java work. The ecosystem is unmatched, the documentation is exhaustive, and a junior engineer arriving on a Spring Boot codebase has a head start. The downside — boot time, memory footprint, runtime reflection — has been substantially mitigated by GraalVM native images and Spring 6's AOT processing. We use it for almost every long-lived enterprise service.
Quarkus
The serious challenger. Built around the assumption that you might compile to a native binary and run on Kubernetes with millisecond startup. Sub-100ms cold starts, low memory ceilings, sensible defaults. For greenfield microservices where deployment density matters, Quarkus is now our first thought.
Micronaut
The third major framework in this space. Compile-time DI rather than reflection. Smaller community than Quarkus but equally credible technology. We reach for it when an existing team has experience with it.
Helidon
Oracle's offering. Two flavours: SE (programmatic) and MP (declarative MicroProfile). Solid technology that doesn't get enough attention because Oracle's brand makes some teams nervous. If you need MicroProfile compliance, it's worth considering.
What changed in the last five years
Native images are routine
GraalVM native compilation is no longer the exotic option. We ship Quarkus and Spring Boot apps as native binaries by default for anything serverless-shaped. The build time penalty is real but the runtime profile — fast start, low memory — pays for itself within weeks.
Virtual threads changed the threading conversation
Java 21 virtual threads (Project Loom) mean you can write blocking code without paying the thread-per-request memory cost. Whole categories of "we have to go reactive" decisions can now be revisited. Reactive frameworks like WebFlux or Vert.x are still valid choices, but they are no longer the only path to high concurrency.
Records and sealed types make modelling pleasant
Domain modelling in Java circa 2026 looks more like Kotlin or Scala than the JavaBeans of the 2010s. Records, sealed types, and pattern matching cover most of what you used to reach for Lombok or third-party libs to provide.
How we choose
- Existing team on Spring? Stay on Spring Boot. Don't migrate for fashion.
- Greenfield service, latency or density sensitive? Quarkus with native compilation.
- Greenfield monolith with a year of features ahead? Spring Boot, possibly with native compilation later.
- Tiny tools and one-off APIs? Honestly, consider a different language. Java's ergonomics for 200-line services are still rough.
What we don't miss
XML configuration. Container vendor lock-in. Six-month deployment cycles. Setting up a CI pipeline that requires a 4GB Docker image. The Java stack is meaningfully better in 2026 than it was a decade ago, and most of the criticism aimed at it now is criticism of a Java that no longer exists.
If you have not looked seriously at the Java ecosystem since 2019, look again. The frameworks haven't just iterated — they've repositioned.