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.
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.
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.