How do virtual threads compare to reactive programming (Project Reactor / RxJava)?

Both virtual threads (Java 21) and reactive frameworks solve the same underlying problem: how to serve many concurrent I/O-bound requests without blocking OS threads, which are expensive. They solve it very differently.

// Reactive style (Spring WebFlux)
Mono result = userRepository.findById(id)        // Mono
    .flatMap(user -> orderRepository.findByUser(user.id())) // Mono
    .map(order -> order.summary())
    .onErrorReturn("default response");

// Virtual thread style (Spring Boot 3.2+ with Tomcat virtual threads)
String result;
try {
    User  user  = userRepository.findById(id);    // blocking — parks VT
    Order order = orderRepository.findByUser(user.id()); // same
    result = order.summary();
} catch (Exception e) {
    result = "default response";
}

// Spring Boot 3.2 — enable virtual threads for Tomcat:
// spring.threads.virtual.enabled=true
// All @RequestMapping handlers run on virtual threads automatically

The consensus in the Java community for Java 21+: prefer virtual threads for new applications — the code is simpler, debuggable, and compatible with the existing JDBC/HTTP ecosystem. Reactive programming remains justified when you need fine-grained back-pressure, stream operators for event pipelines, or when integrating with reactive middleware that does not have a blocking API.