Speaking with TFiR, Simon Ritter of Azul explained how JDK 26’s HTTP/3 API support represents a fundamental protocol shift for Java microservices architectures, switching from TCP to UDP to improve performance while maintaining reliability guarantees through protocol-level ordering and retransmission mechanisms.

WHAT IS HTTP/3 AND WHY DOES IT USE UDP INSTEAD OF TCP?

HTTP/3 is the latest version of the Hypertext Transfer Protocol that switches the underlying transport mechanism from TCP (Transmission Control Protocol) to UDP (User Datagram Protocol). TCP is a reliable protocol that guarantees packets arrive in order with automatic retransmission of lost packets, but this reliability comes with performance overhead. UDP is an unreliable protocol that sends packets without guarantees about ordering or delivery, but offers superior efficiency for packet transmission.

“The way that HTTP/3 works is by switching from using TCP as the high-level protocol to using UDP. UDP allows you to be more efficient in terms of how you send packets. TCP is what’s called a reliable protocol, meaning that the packets you send are received in the order in which they were sent, and there is a mechanism for retransmission if necessary. So, if a packet gets lost, it will be resent. UDP is basically an unreliable protocol, which means that if packets get lost, that’s too bad, and packets may not arrive in the right order.”

HTTP/3 solves the reliability problem by implementing ordering and retransmission guarantees at the application protocol level on top of UDP’s efficient but unreliable foundation.

Building Reliability on Top of UDP for Microservices

For distributed microservices architectures and web applications, data must arrive intact and in the correct order. HTTP/3 addresses this requirement by building reliability mechanisms into the protocol itself while still benefiting from UDP’s performance advantages.

“HTTP/3 has to build on top of UDP to give you that reliability, because if you’re sending web pages or working with microservices, what you want is to be able to send data and have it arrive in the form in which it was sent. It doesn’t really work very well if you don’t get the right data. HTTP/3 solves those problems while still allowing you to use a higher-performance protocol. So it’s kind of a combination of things.”

This architectural approach enables Java microservices to achieve better throughput and lower latency for distributed communication while maintaining the data integrity guarantees that production applications require.

Broader Context: Project Loom Structured Concurrency Timeline

In this TFiR interview, Simon Ritter also provided a timeline update for Project Loom’s structured concurrency feature, which remains in preview status in JDK 26 but is expected to finalize by 2028.

“I would think that structured concurrency may be a full feature in the next release, and certainly by the release after that—so, 2028—I’m sure it will be included. It is part of Project Loom, which is one of those large projects like Valhalla and Panama. We’ve had virtual threads, and we’ve seen structured concurrency and other related features. They’re kind of putting the finishing touches on the components of Project Loom.”

Project Loom represents a major evolution in how Java handles concurrency, introducing virtual threads and structured concurrency primitives that simplify multi-threaded programming. The timeline suggests that while individual components like virtual threads have already reached production status, the final pieces including structured concurrency are nearing completion after several preview iterations.

“When I looked at the JEP, there weren’t any significant changes between the previous release and this one. So I would imagine that once people have had a look at that and are happy with it, they will finalize it.”

The lack of significant changes between preview iterations indicates that structured concurrency’s API design has stabilized, with finalization primarily dependent on real-world validation from teams testing the feature in production-adjacent environments.