General Plans for Individual Specifications in Jakarta EE 11

One of the major themes of the upcoming Jakarta EE 11 release, slated for the first quarter of 2024, is further innovation and addition of new features. But, as always, keeping house and tidying up are always going to be important parts of any major release. 

In this article we’ll discuss both. The Jakarta Server Pages 4.0 specification release is largely a case of cleaning up, whereas the Jakarta NoSQL and Jakarta Data specifications are new to Jakarta EE. 

Jakarta Server Pages 4.0 Cleanup

At this point, the Server Pages specification is very much in maintenance mode. It functions well and does what it needs to. That said, some cleaning up of the code was warranted.

One change worth noting is a follow-up to a change in the expression language specification. Because that specification relies on the Java Bean specification, and Server Pages relies on the expression language specification, Server Pages ended up with a dependency on the Java desktop module. That was less than ideal. Prior work on the expression language deprecated those parts of the API creating the dependency, and recent work removed them entirely. So that’s had a knock-on effect for Server Pages. We’ve removed that functionality entirely because you don’t want dependencies you don’t need. 

The “isThreadSafe” page directive has also been removed. This aligns with the Jakarta Servlet specification where the “SingleThreadModel” interface was deprecated for a long time and then removed in Servlet 6.0. That deprecation again had a knock-on effect on Server Pages. Without the “isThreadSafe” page directive, users will no longer have the option to execute a server page using only one thread at a time. 

We also removed the ability to embed Java applets in browsers. This was a neat idea that enables a lot of different things. Unfortunately, it turned out to be a nightmare from a security perspective, and for the most part, browsers don’t let you do that anymore. But it was still possible in Server Pages. We deprecated it last release and removed it with this one.

These are relatively minor changes, as these features are basically never used. And unless something unexpected happens, the future of Server Pages will be fixing any unexpected issues and adapting to changes in servlet expression language. 

Jakarta NoSQL Enhances Database Capabilities

The Jakarta NoSQL specification brings a powerful Java capability into Jakarta EE. In this case, the ability to use NoSQL databases.

These days there are a great many databases, each of which is suited to a specific task. There’s the idea of polyglot language, where part of finding the best solution to a problem is using the best language. Previously in Jakarta EE, developers could only use the relational database type to do that. 

The NoSQL project not only brings the ability to use this alternative database type to Jakarta EE but also makes it easier to do so by providing a standardized API for the different individual databases. Instead of having to learn 200 different APIs for the 200 different database types, developers will only have to learn one. 

Jakarta Data Facilitates NoSQL and JPA

Another specification is for the persistence layer. 

The idea behind Jakarta Data is that, with the release of Jakarta NoSQL, developers can now use both relational and NoSQL databases. We want to facilitate that usage by building off their similarities to make an API that you can use with either. That’s where Jakarta Data comes in. 

The idea is to use the repository approach that provides users with an interface where they can request an implementation. Sort of like ChatGPT, where you input a query and receive an answer. But in this case, users input their query and get an implementation. 

This functionality includes a pagination ability because an implementation can be enormous. So rather than having to input a query that sends back an enormous wall of code that developers then have to sift through to find what they need, we’ve introduced the idea of requesting particular pages, so users can limit the data they receive to what they need. 

Find out more about the Jakarta EE 11 release plan on GitHub.