Towards a Community Vision for
Jakarta EE 10

Now that Jakarta EE 8 has been delivered and Jakarta EE 9 is almost complete, there’s no reason work on Jakarta EE 10 should not begin. Ideally, Jakarta EE 10 will be released by late 2021 to meet the community’s long-time request for one major platform release a year.

To keep the platform fresh and relevant, Jakarta EE 10 must deliver a compelling set of updates. For several months, the Jakarta EE Ambassadors have been drafting a contribution guide to help shape Jakarta EE 10 and facilitate community contribution. So far, three key themes have emerged:

• Contexts and Dependency Injection (CDI) alignment
• Java Standard Edition (SE) alignment
• Closing standardization gaps

In my view, these are modest, but much needed, changes, especially in the context of releases such as Java EE 7 and Java EE 8. They represent long-standing items with good community consensus and prior discussion in the Java EE 6, Java EE 7, Java EE 8, and Java EE 9 timeframes (Oracle had publicly shared the Java EE 9 scope before the technology was transferred to the Eclipse Foundation).

Here’s a brief summary of the Jakarta EE 10 changes currently envisioned in the Jakarta EE Ambassadors’ draft document.

Improving CDI Alignment

Since its introduction in Java EE 6, Jakarta CDI has become the central component model in the platform and many parts of the platform already align with it. Key examples include:

• Defining @Transactional in Jakarta Transactions
• Managed bean deprecation in Jakarta Server Faces
• Use of CDI in Jakarta Security

However, parts of the platform still need to take better advantage of CDI:

• Many useful features remain specific to the dated and redundant Jakarta Enterprise Beans programming model. These features could be made more flexibly available anywhere CDI is enabled. Once modernized to be implemented through CDI, these features could be moved into the specifications where they make best sense. Examples include:
  • Defining @Asynchronous, @Schedule, @Lock, and @MaxConcurrency in Jakarta Concurrency
  • Defining Message-Driven Bean style @MessageListener in Jakarta Messaging
  • Moving @RolesAllowed, @RunAs to Jakarta Security
• Additional specifications could make their artifacts injectable using CDI, deprecate their own features in favor of CDI, and better integrate with CDI. For example:
  • Jakarta Batch artifacts could be made injectable using CDI.
  • Jakarta RESTful Web Services could deprecate @Context in favor of CDI injection.
  • Jakarta Concurrency could better handle CDI context propagation.

Improving Java SE Alignment

Java EE has a long history of adapting to Java SE innovations. Java EE 5 was the first mainstream technology to prove usage of annotations as metadata. And Java EE 8 embraced Java SE 8 features such as repeatable annotations, the Date-Time API, and CompletableFuture.

There are opportunities to further take advantage of Java SE in Jakarta EE 10. For example:

• Jakarta Concurrency is not fully aligned with Java SE 8. The API could be adapted to properly use CompletableFuture.
• An increasing number of Jakarta EE technologies, such as CDI, can be used outside the platform as a standalone technology. This capability makes platform technologies more usable and flexible. In Jakarta EE 10, this concept could be extended. For example, Jakarta Messaging and Jakarta RESTful Web Services could provide standalone bootstrap APIs.
• An important step toward making more technologies usable in Java SE is using Arquillian and JUnit 5 to modernize technology compatibility kits and make them standalone. While some amount of progress toward this objective was made in Jakarta EE 9, more work is needed.

Closing Standardization Gaps

One of the platform’s key value propositions is that it provides portability and vendor neutrality for the broadest set of users in the ecosystem. This is achieved by standardizing commonly used features that are vendor-specific or available outside of Jakarta EE. There are opportunities in this area that represent long-standing feature gaps. For example:

• Jakarta Security currently provides out-of-the-box support for databases and LDAP for authentication and authorization. The API could be modernized to add support for OAuth2, JavaScript Object Notation (JSON) Web Token (JWT), and OpenID Connect.
• Jakarta Batch could be updated with a Java job definition API as an alternative to XML. Some implementations make this possible today.
• Jakarta Concurrency could add @ManagedExecutorServiceDefinition to increase portability when defining managed executors.
• A microservices profile that initially consists of CDI, REST, and JSON APIs could be introduced. This small profile could be the foundation for Eclipse MicroProfile runtimes. The profile would require creation of a lighter version of CDI that includes a subset of features targeting Jakarta EE, but a superset of features targeting the core CDI and Java SE.
• Jakarta Messaging interoperability with the Advanced Message Queuing Protocol (AMQP), Apache Kafka stream-processing software platform, and MQ Telemetry Transport or Message Queuing Telemetry Transport (MQTT) protocol could be explored. This could require creation of a lighter weight profile and deprecation of some older, less frequently used features.
• It may be possible to support JCache as a second-level Jakarta Persistence cache or application server state cache.
• Jakarta Transactions could standardize common optimizations such as last resource commit, one-phase commit, and local transactions. The Oracle WebLogic Server supports such features today and they could be contributed as a basis for standardization.

Potential New Specifications in Jakarta EE 10

A few new APIs could be added to the Jakarta EE 10 platform. The following APIs were proposed by Oracle for Java EE 9 and represent standardization gaps:

• Jakarta NoSQL and Eclipse JNoSQL aim to enable NoSQL access for Jakarta EE applications. Jakarta NoSQL could initially be added as an optional part of the Jakarta EE platform.
• Jakarta Model-View-Controller (MVC) was started in Java EE 8 and aims to provide a more action-oriented Java web framework for Jakarta EE applications. It could initially be added as an optional part of the Jakarta EE platform.
• Adding the ability to externalize configuration is a long-standing gap that’s been discussed since Java EE 7. A key goal is to enable specifications that need significant configuration to consume it from outside the application, such as from the environment. Specifications that could use this functionality include Jakarta Persistence, Jakarta Messaging, and Jakarta Mail. It’s possible this need could be met through alignment with Eclipse MicroProfile.

Looking Beyond Jakarta EE 10

There are a few additional changes on the horizon, but they won’t likely be ready for Jakarta EE 10. Most will benefit from further maturity, analysis, development, and experimentation. They include:

• Jakarta Persistence alignment with Java SE Records
• More reactive non-blocking input/output (NIO) capabilities in:
  • Jakarta Servlet or an equivalent lighter layer
  • Jakarta Persistence, which requires a widely supported version of reactive NIO Java Database Connectivity (JDBC) first, ideally in Java SE
  • Jakarta Restful Web Services
  • Jakarta MVC

Review the Draft Contribution Guide

While there’s already been a reasonable amount of community review on the Jakarta EE Ambassadors’ Jakarta EE 10 contribution guide, more reviews are welcome.

The objective is to finalize the draft by early 2021 and begin moving forward with Jakarta EE 10. Even though the guide is high-level, there are work items I didn’t cover in this brief article, so reading the draft is worthwhile even if you don’t have feedback.

Access the draft Jakarta EE Ambassadors’ Jakarta EE 10 contribution guide here on Google Docs.