The 5 things devs should know about the Jakarta Servlet 6.0 API release

1. We’ve removed deprecated methods

Our decision to remove deprecated methods from the Jakarta Servlet specification is certainly not the most important change in Servlet 6.0, but it is the one about which we’ve received the most feedback and concern, so I want to address it first.

We consider the removal of these deprecated methods to be a brave, but very necessary, step towards the future. To move the Servlet technology forward, we must eliminate some of the burdens of its past. Technologies have come a long way since the Servlet specification was first released in 1996, but historically, we were not allowed to implement changes that would break backwards compatibility. If not now, then when? It will never be a good time to implement such a change.

Hopefully, very few Servlet implementations still rely on the deprecated methods, but those that do may behave differently and will need to be updated.

Please don’t get the idea that we’ll be introducing a breaking change in every Servlet release. While the namespace change from javax.* to jakarta.* in Jakarta Servlet 5.0 was also a breaking change, that update was a strategic decision that affected every Jakarta EE specification. And we’ve been very pleased to see the number of users that have already moved to the Servlet 5.0 specification and the new namespace.

Going forward from Servlet 6.0, we expect to continue with a strong focus on backwards compatibility to make life as easy as possible for Java developers. There will be a series of 6.x releases that will allow us to incrementally add new ideas and features that won’t be constrained by the cruft of the past.

2. Object wrapper identity requests and responses are durable

The most important change in the Jakarta Servlet 6.0 API also involves removing existing functionality. We’ve reduced the number of object wrapper identity features to make requests and responses immutable rather than mutable.

The ability to implement durable, immutable requests and responses allows developers to create better Servlet containers when asynchronous programming is used. While technologies such as Loom resolve some of the challenges associated with asynchronous programming, there will still be cases where developers want to explicitly manage asynchronicity. And there was an intrinsic race condition that occurred when asynchronous programming was used with the Servlet technology.

With durable requests and responses, developers have the flexibility to use asynchronous programming when needed with no need to worry about creating a race condition.

Reducing the number of object wrapper identity features also increases portability between containers because there’s no need to worry about the different behaviors between containers when very specific capabilities are implemented.

Developers whose Servlet implementations relied on the bad practices the object wrapper identity functionality allowed in the past will have to rethink the way they do things. But they’ll have a much better container implementation.

3. URI security protections are defined

In Servlet 6.0, we’ve spent a lot of time defining all of the different security protections associated with URIs — uniform resource identifiers.

In the past, the URI path that was passed to the application was just a string. Because URIs can be encoded, this meant it was often difficult to know whether a slash was a URI separator or part of the encoding. Also, changes made to the URI specification along the way have allowed more flexibility in the way dots and semicolons are interpreted.

Previously, developers had to determine how to handle each URI case and work behind the scenes to implement the solution in the application server. We’d all come up with very similar solutions, but they weren’t defined anywhere. It was a bit like having to know the dark arts of Servlet security.

Now that URI security protections are openly defined in the Servlet specification, developers can add their security protections on the front end, away from the application server. We can ensure there’s a consistent approach to URI security across Servlet implementations. And Servlet containers can be integrated into broader security environments.

4. There’s more freedom with cookies

Servlet 6.0 also allows developers to add new attributes to a cookie without creating an API dependency.

Cookies are key to web app security, but it’s been very difficult for the Servlet specification to keep up with all of the new cookie attributes that have become required because the entire specification had to be released. Now that we’ve eliminated the API dependency, it’s easy for developers to add the latest required cookie attributes by simply setting up a trigger.

This is another way we’re working to make the Servlet specification more flexible and more closely aligned with the speed at which technology moves today. It’s also great for those of us who work on the specification because we don’t have to tie Servlet releases to cookie security updates.

5. Every Servlet implementation can benefit from Servlet 6.0

With Servlet 6.0, the only thing we’re leaving behind is our own worst practices — programming models and functionality that were supported in the specification but haven’t been best practices for decades.

The improvements in Servlet 6.0 allow developers to build faster, simpler, and more scalable core server implementations that can compete with servers that only support HTTP. And they will no longer have to deal with the legacy complexities in Servlet.

These benefits can be applied to all Servlet implementations, even those written 15 years ago. As long as developers port their implementation to Servlet 5.0 to make the namespace change and are not using any of the deprecated methods, taking advantage of the new speed and flexibility enabled in Servlet 6.0 is quite straightforward.

Stay engaged with Jakarta Servlet

We’re a very open and approachable community and we want to hear from you — whether you simply have a question, you think we’ve missed something, you’re outraged by a change, or you’re looking for a new feature. We also welcome everyone who wants to help with testing.

The best place to engage with us is GitHub.

About the Author

Greg Wilkins is the founder of Mort Bay Consulting and chief architect at Webtide, LLC. He’s also a project lead on Eclipse Jetty and a committer on Jakarta Servlet.