Why Spring Boot 4.0 Dropped Undertow Support and What It Means for Your Projects

Last week Spring Boot 4.0 RC1 was officially released, bringing many important improvements. One change that attracted widespread attention is the complete removal of support for the Undertow web container.

For enterprises and developers using Undertow, this means that projects must migrate to a different web container when upgrading to Spring Boot 4.0.

If a project includes the following dependency, the build will fail because Spring Boot 4.0 no longer provides automatic configuration and dependency management for Undertow:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>

The Spring team created a dedicated GitHub Issue #46917 to track this change and ensure transparency.

"Spring Boot 4.0 requires a Servlet 6.1 baseline, and Undertow is currently not compatible. Therefore, we have dropped support for Undertow."

The core problem is a version dependency mismatch, a technical compatibility issue rather than a performance or design choice.

Undertow’s maintainers at Red Hat have a relatively slow development pace, leaving enterprises with limited options when upgrading to Spring Boot 4.0.

Servlet 6.1 Technical Feature Analysis

Release Background

Servlet 6.1 was released in April 2024 as the core sub‑specification of Jakarta EE 11, bringing many important modernizations to Java web development.

Key New Features

1. ByteBuffer Support – Added to ServletInputStream and ServletOutputStream, greatly improving non‑blocking I/O performance for high‑concurrency scenarios.

// Use ByteBuffer to read request data
ByteBuffer buffer = ByteBuffer.allocate(1024);
servletInputStream.read(buffer);

2. HTTP/2 Server Push Deprecated – The feature is removed due to its declining usage in modern web applications.

3. SecurityManager APIs Removed – All references to the deprecated Java SecurityManager are eliminated, simplifying the security architecture.

4. Enhanced HTTP Session Mechanism – Provides better support for WebSocket scenarios and more flexible session management.

5. Improved HTTP Redirect Control – Developers now have finer control over status codes and response bodies when issuing redirects.

// Custom redirect response
response.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY);
response.setHeader("Location", newUrl);
response.getWriter().write("Resource has moved");

6. Sensitive Header Handling – Introduces HttpServlet.isSensitiveHeader to identify and protect headers such as Authorization, Cookie, and Forwarded.

7. Conditional GET Optimization – Improves network efficiency via the getLastModified method.

Jakarta EE 11 Specification

Jakarta EE 11 is the latest enterprise Java platform, with Servlet 6.1 as its core sub‑specification, providing a unified framework for modern enterprise applications.

The platform also introduces the Jakarta Data specification to simplify persistence logic.

Core Features of Jakarta Data

1. BasicRepository Interface

public interface ProductRepository extends BasicRepository<Product, Long> {
    // Provides save(), findById(), findAll(), delete()
}

2. CrudRepository Full CRUD

public interface UserRepository extends CrudRepository<User, String> {
    List<User> findByEmailContaining(String email);
    Page<User> findByStatus(UserStatus status, PageRequest page);
}

3. Pagination Support – Both offset‑based and cursor‑based pagination are available, offering performance advantages for large data sets.

// Offset‑based pagination
Page<Product> findByCategory(String category, PageRequest pageRequest);

// Cursor‑based pagination
CursoredPage<Product> findByPriceGreaterThan(BigDecimal price, PageRequest pageRequest);

4. Query Language – A concise query language simplifies method‑level queries.

public interface OrderRepository extends CrudRepository<Order, Long> {
    @Query("SELECT o FROM Order o WHERE o.status = ?1 AND o.total > ?2")
    List<Order> findHighValueOrders(OrderStatus status, BigDecimal minTotal);
}

Mainstream Web Container Support Comparison

The compatibility matrix shows that Undertow is the only major web container that does not yet support Servlet 6.1, which is the fundamental reason Spring Boot 4.0 removed its support.

Two years ago, the community promoted Undertow as a lightweight, high‑performance alternative to Tomcat, citing lower memory usage, superior concurrency via XNIO, and flexible configuration.

Lightweight memory footprint : Faster startup and lower resource consumption.

Excellent concurrency performance : Non‑blocking I/O model based on XNIO.

Flexible configuration : Programmable server settings.

Many enterprises adopted Undertow at scale, and Spring Boot documentation listed it alongside Tomcat and Jetty as a recommended container.

However, as Jakarta EE and Servlet specifications evolved rapidly, Undertow’s update pace lagged, turning a once‑preferred “performance choice” into an “upgrade obstacle”.

This lesson shows that technology selection should consider not only current performance metrics but also ecosystem vitality and long‑term evolution; sometimes a stable mainstream option is more reliable than a cutting‑edge alternative.