Enhanced Concurrency for Your Jakarta EE Applications

In our latest release blog post, we announced the availability of a new version of Payara Platform Community 7 Alpha, which gives developers a more snapshot view of the upcoming Jakarta EE 11 features, helping them get closer to the technology. In particular, the March release of Payara Platform Community delivers game-changing concurrency improvements.

Let’s dive into what this means for your applications and your projects as well as how it can enhance developer productivity. 

What is Concurrency?

First things first: What does concurrency mean? Concurrency refers to the ability of a system to execute multiple tasks or processes simultaneously through, among other features, simultaneous execution, task independence and resource sharing. Concurrency is therefore extremely beneficial in Java and Jakarta EE programming, as it supports efficient utilization of resources, improved system responsiveness and performance.

While the Java and Jakarta EE platforms are designed to offer concurrent programming capabilities, handling concurrency in an application can be a challenging process and, if it isn’t done right, it can lead to a number of issues, such as race conditions, deadlocks, starvation and livelocks, limited scalability as well as overall performance bottlenecks. To learn more about why we need concurrency, check this piece.

A Brief History of Jakarta Concurrency

As technology evolves and the requirements for today’s applications become more ambitious, delivering ever more advanced concurrency features is a must for any platform to remain valuable to developers. Jakarta Concurrency, formerly known as Java EE Concurrency, has evolved significantly since its inception. Here’s a look at its journey:

• Java EE 7 (2013) – The Birth of Concurrency Utilities: Before Java EE 7, enterprise Java applications had to rely on Java SE’s java.util.concurrent package or vendor-specific solutions, which lacked container integration and were not managed by the application server. Java EE 7 introduced Jakarta Concurrency 1.0 (then called Java EE Concurrency Utilities) as a standardized way to handle asynchronous tasks inside application servers.
• Java EE 8 (2017) – Stability and Minor Improvements: Java EE 8 saw minor refinements to concurrency utilities but no major changes with Jakarta Concurrency 1.1. At this stage, reactive programming was gaining traction, but the concurrency model remained largely imperative.
• Jakarta EE 9 & 10 (2020-2022) – Namespace Change and Preparations for the Future: With Jakarta EE 9, the APIs were migrated from javax to jakarta and Jakarta Concurrency 2.0 was established, but everything retained the same functionalities. Jakarta EE 10 laid the groundwork for future concurrency improvements, aligning Jakarta Concurrency 3.0 with modern Java updates but without introducing major changes.

Key Concurrency Enhancements in Jakarta EE 11

To further support developers, Jakarta EE 11 introduces several notable updates to the Jakarta Concurrency API, leading to Jakarta Concurrency 3.1. This is aimed at simplifying and enriching concurrent programming. Thanks to these new elements, Jakarta EE 11 Platform is well positioned to help enhance developer productivity and help software experts leverage modern Java capabilities, particularly in response to the introduction of Virtual Threads in Java 21.

This is what you can find in Jakarta Concurrency 3.1:

• Virtual Threads Support: One of the most anticipated features is the support for virtual threads when running on Java SE 21. This enhancement significantly boosts the concurrency model in Jakarta EE, offering improved scalability and performance.​
• @Schedule and @MaxConcurrency Annotations: These new additions streamline the process of creating and managing concurrent tasks while reducing boilerplate code. @Schedule makes scheduling of asynchronous methods extremely straightforward by using cron expressions or specific time parameters. As a result, you can streamline task automation within your applications.​ @MaxConcurrency limits the number of concurrent executions for a particular method or bean, helping manage resource utilization and prevent overload.
• Integration with Java 9 Flow and Reactive Streams: You can now harness asynchronous, reactive data processing, facilitating the creation of responsive and efficient systems.
• Dependency Injection for Concurrency Resources: With ManagedExecutorService and ContextService now injectable as CDI beans, resource management becomes more intuitive, promoting cleaner and more testable codebases.​

Jakarta EE 11 Core Profile in Payara Platform Community 7 Alpha

The latest alpha release of Payara Platform Community is compliant withJakarta EE 11 Core Profile, which defines a profile of the Jakarta EE platform specifically targeted at smaller runtimes. Payara Platform Community 7, expected to be fully Jakarta EE 11 compliant, is anticipated to align with the Eclipse Foundation’s release timeline of Jakarta EE 11 Full Profile later in the year.

With Virtual Threads being the star of Jakarta Concurrency 3.1, our engineering team developed an intuitive demo for you to get acquainted with the feature, its capabilities and the opportunities it offers. More precisely, it compares how a sample application can perform with virtual threads vs. without (pre-Jakarta EE 11 and Java 21).

Available on GitHub, you can access the concurrency demo here.

Payara Platform Community 7 Alpha Development Considerations

While this alpha release provides an opportunity to explore Jakarta EE 11 features, it’s important to note:

• This is an early preview and not intended for production use, like any Payara Platform Community version. To learn why, check this blog post.
• This preview only covers the Jakarta EE 11 Core Profile, while the final Jakarta EE 11 Full Profile specification is being finalized.
• Developers are encouraged to test existing projects for compatibility – We’d love to hear your feedback!