Mocking is an essential part of unit testing, and the Mockito library makes it easy to write clean and intuitive unit tests for your Java code.
Get started with mocking and improve your application tests using our Mockito guide:
Handling concurrency in an application can be a tricky process with many potential pitfalls. A solid grasp of the fundamentals will go a long way to help minimize these issues.
Get started with understanding multi-threaded applications with our Java Concurrency guide:
Spring 5 added support for reactive programming with the Spring WebFlux module, which has been improved upon ever since. Get started with the Reactor project basics and reactive programming in Spring Boot:
Since its introduction in Java 8, the Stream API has become a staple of Java development. The basic operations like iterating, filtering, mapping sequences of elements are deceptively simple to use.
But these can also be overused and fall into some common pitfalls.
To get a better understanding on how Streams work and how to combine them with other language features, check out our guide to Java Streams:
Explore Spring Boot 3 and Spring 6 in-depth through building a full REST API with the framework:
Yes, Spring Security can be complex, from the more advanced functionality within the Core to the deep OAuth support in the framework.
I built the security material as two full courses - Core and OAuth, to get practical with these more complex scenarios. We explore when and how to use each feature and code through it on the backing project.
You can explore the course here:
Spring Data JPA is a great way to handle the complexity of JPA with the powerful simplicity of Spring Boot.
Get started with Spring Data JPA through the guided reference course:
Refactor Java code safely — and automatically — with OpenRewrite.
Refactoring big codebases by hand is slow, risky, and easy to put off. That’s where OpenRewrite comes in. The open-source framework for large-scale, automated code transformations helps teams modernize safely and consistently.
Each month, the creators and maintainers of OpenRewrite at Moderne run live, hands-on training sessions — one for newcomers and one for experienced users. You’ll see how recipes work, how to apply them across projects, and how to modernize code with confidence.
Join the next session, bring your questions, and learn how to automate the kind of work that usually eats your sprint time.
1. Overview
In this tutorial, we’ll talk about the newest release of Jakarta EE. The idea is to understand what is new in Jakarta and how this can impact the Java platform.
By the end of it, we hope you understand the changes in Jakarta and its near future.
2. What Is Jakarta EE
The Jakarta EE is an open-source framework for developing web applications in Java or, as currently stated, cloud-native Java. Previously known as Java EE (Java Enterprise Edition), developed and maintained by Oracle through JCP (Java Community Process). However, a few years ago, more precisely in 2017, the Eclipse Foundation took over the project. Still, the two organizations could not agree, and the project could not continue using the javax.* and java.* trademarks. That is the reason why now the project is called Jakarta.
The project’s main idea always was to standardize and provide a set of vendor-agnostic specifications so that Java applications could easily be ported from one vendor implementation to the other. This would ensure flexibility, reliability, stability, interoperability, and quality between the vendors.
Jakarta EE now uses the JESP (Jakarta EE Specification Process). The process guarantees that all specifications contain the following:
- Documentation of the specification and JavaDocs.
- APIs defined for the given specification.
- TCK (A Technology Compatibility Kit) and documents that define the tests that must be implemented to ensure specification compliance.
- At least one implementation following the TCK.
3. Jakarta EE Releases
Now that we understand that Jakarta EE is a framework that provides a set of specifications so other vendors can implement them in a standard way. Let’s review the recent past of this project.
Since the Eclipse Foundation took on the project, no new features have been introduced to the project. During this time, the only changes delivered were the following:
- Version 8: Full compatibility with Java version 8.
- Version 9: Breaking release changing the namespace to jakarta.* instead javax.*.
- Version 9.1: Support for Java 11.
As one may imagine, for the developer, the last releases haven’t been as exciting as they could be. However, this gave them time to mature other discussions, such as lightweight applications like MicroProfile and other possible future specifications.
4. Jakarta EE 10
Now that it’s clear what Jakarta EE is and how we got there. Let’s discuss its most recent release, Jakarta EE 10.
These last releases focus on making Jakarta a robust framework that allows innovation through cloud-native Java applications. Or, in their own words, “Jakarta EE 10 is now available and introduces features for building modernized, simplified, and lightweight cloud-native Java applications, delivering a new baseline for the evolution and innovation of enterprise Java technologies under an open, vendor-neutral, community-driven process.”
As mentioned, this release is the most relevant since the control change in the project’s development and coordination. There were over 20 component specifications changes between new functionality, internal changes, deprecations and removals. The release now targets Java 11 but also supports Java 17, the current LTS version. Moreover, the platform now supports JPMS:
In terms of additions to the platform, the two big news are a new component specification called CDI Lite 4.0 and the new Jarkarta Core profile. Next, let’s dive deeper into some new additions and smaller changes.
4.1. New Components
The brand new CDI Lite 4.0 component specification focus on offering a smaller subset of features already available on the CDI specification. It targets shorter run times like Micronaut, Quarkus, Helidon, and more, and also will support the possibility of compiling to native using GraalVM. Therefore, many dynamic features had to work at build time, and some features had to be rewritten, such as extensions. Some other critical features were removed as the target is smaller runtimes.
Continuing in the direction of smaller runtimes, the new Core Profile specification came to try standardizing such MicroProfiles, and the frameworks mentioned above. Using a subset of specifications like the Web Profile but without some user focus specifications, for instance, Faces. This specification aims to make the development of microservices or smaller applications easier by reducing the learning curve and making them more portable.
4.2. Component Updates
The complete list of updates in the platform is significant, but some of the highlights are the following:
- Web Profile 10: Concurrency and resource management are now part of this specification
- Security 3.0: New authentication method OpenId connects, standardizing this technology’s implementation across different vendors. Minor internal updates and deprecation of some older things
- Persistency 3.1: Adding support to UUIDs and UUID generation strategy for primary keys and, again, standardizing the usage across vendors
- Restful APIs 3.1: Multipart/form-data support download and upload. New bootstrap API to run jars without needing application servers and @Context deprecated
- EJB 4.0: Remove entity beans, embeddable EJB container
- Faces 4.0: Remove support for JSP support, managed beans, resource resolver, and more. New type Safe faces views and @ClientWindowScoped
- CDI 4.0: Discovery mode now defaults to annotated instead of all. So if the beans.xml is empty, only annotated beans will be discovered by default
- Servlets 6.0: All classes and methods marked as deprecated previously were removed
- Batch 2.1: Better CDI support
Apart from that, related to concurrency, new annotations were added to manage resources and control the execution of tasks @ManagedExecutionDefinition and @Asynchronous.
4.2. Future
Although this release brings a lot of new features and concepts to the platform, there are still lots of discussions happening in the community and the project forums. The conversations about the next release, Jakarta 11, have already started, and the future promises even more innovations. Examples of expected new specifications are RPC, Data, Config, and NoSQL. Always aiming to modernize, simplify and standardize such technologies in the platform.
5. How to Migrate?
However, to leverage all these new features and capabilities, upgrading the version and migrating to Jakarta 10. Many tools may help us migrate; nonetheless, in case we decide to go through this path, there are some steps we need to make sure to follow:
- Update the Jakarta version in the POM/Gradle or preferred build tool
- Fix the imports from javax.* to jakarta.*
- Fix XML schema namespaces, like persistency XML and others
- Rename properties prefixes. Similar to the package namespace, the properties prefixes also changed
- Rename bootstrapping files, same as above
- Verify application behavior
By following all the steps, we can possibly migrate our application with little to moderate effort.
6. Conclusion
In this article, we studied the new Jakarta EE 10 release, the evolution brought to the platform, and some of its nuances. Moreover, we also looked at the near future of the project and possible upcoming specifications. Last, we understood all the steps necessary to move from any version older than version 9.0 to the latest release version.
Hopefully, now we know more about this important milestone in the platform’s history and decide whether to consider upgrading or using it in our applications and future projects.
