The Camunda Automation Platform team always aims to support the latest and most widely used application servers for our customers; Wildfly is one of those servers. Thus, our most recent 7.19 release introduces support for Wildfly 27. However, this version comes with some special treats.
What is so special about this Wildfly version?
Wildfly 27 adds support for Jakarta EE 10 and drops support for Jakarta EE 8. Jakarta EE 8 was the last enterprise edition using the javax namespace. Starting with Jakarta EE 9, the EE specifications use the jakarta namespace instead of javax.
From a simple application’s perspective, this means configurations need to be adjusted, dependencies need to be updated to newer versions that also rely on the new namespace, and most importantly, imported package names need to be updated to jakarta.*. Additionally, Jakarta EE 10 also requires Java SE 11.
Jakarta namespace in Camunda Automation Platform
Unfortunately, we cannot update everything at once to the new jakarta namespace completely. We support many environments that would not work after the update otherwise.
We have evaluated the idea of forking our code base. This would allow us to fully move to jakarta in one code base. However, we rejected this idea as it implies a significant long-term effort. Due to the supported environments that still use javax API, we would have to maintain two code repositories with similar business logic but different API bindings in parallel.
Eventually, we decided to embrace both namespaces within our code base.
It was clear that some code duplication was imminent. Classes that rely on javax need to have corresponding classes that rely on jakarta instead. Of course, we have tried to reduce duplication and extract as much logic as possible, but we have components that contain more than a hundred classes with references. For instance, our camunda-engine-rest-core module that contains our REST APIs. Manually duplicating all the classes would not only be a large effort, but would also make the module way more complex and hard to maintain. Not to mention, some artifacts must be duplicated due to configuration files like the web.xml that cannot contain both namespaces at the same time.
Code transformation
We really liked the idea of automatically transforming our components for Jakarta, but we wanted to make sure that the transformation is under our control and the created artifacts go through the same quality checks as the original components.
Therefore, we have decided that if we use this approach, we will only use transformation on the source level. This way, all the sources and resources can be compiled, tested, and packaged just like their original counterparts and we can confidently say that they will work properly without any issues.
There are multiple tools available that can be used to automatically transform resources. We chose the Eclipse Transformer. This is a generic tool for transforming resources, byte code, and artifacts. The project’s original motivation was actually the previously mentioned Jakarta EE namespace change, with that they also offer configurations for this exact use case. They provide a Maven module as well.
Impacted components
With the previous information in mind, we have reduced our options to the following:
- Manually implement the
jakartaversions of the required classes inside the component, if there are only a few. - Create a new
jakartacomponent and generate the sources and resources via code transformation.
These are the most important components that were affected by the namespace change, along with the newly created components, if there is any:
- Engine Core
- Wildfly Distribution
- Engine REST – Engine REST Jakarta and Assembly
- Engine EJB Client – Engine EJB Client Jakarta
- Engine CDI – Engine CDI Jakarta
- Webapps & Plugins – Webapps Assembly Jakarta and Plugins Assembly Jakarta (Enterprise feature)
- Camunda Spin – DOM XML data format Jakarta
Interestingly, apart from the Engine Core and Wildfly Distribution, we have applied the second approach mentioned above for every component. That is, all these components now have a jakarta-specific component which is created using code transformation. As stated before, these components go through the same quality checks.
In the Engine Core we have decided to keep the jakarta-specific classes inside the module, mainly because there were only approximately 10 classes that directly used javax. All the other modules were either heavily relying on the javax namespace or produced an artifact that must be bound to one namespace only.
Finally, in the Wildfly Distribution we are now building the artifacts for the latest Wildfly 27 version, thus it only contains the jakarta namespace. For previous versions, we have created compatibility modules.
For convenience, the jakarta components use the same artifact ID with an additional -jakarta suffix. For example, camunda-engine-cdi and camunda-engine-cdi-jakarta.
What does this mean for our customers?
If you are not using the Wildfly application server, the namespace change will not affect you in any way.
If you are using a Wildfly application server and would like to update to 7.19, the update process slightly changes depending on your server’s version because our default pre-packaged distribution is now Wildfly 27. Make sure to read our Update & Migration guide and pay attention to the differences between the latest (27) and older versions (≤26 / JBoss EAP 7).
If you are looking for a new Wildfly 27 setup, you can download our pre-packaged distribution. On the other hand, an older Wildfly application server requires Manual Installation.
Want to see more?
This is our Wildfly 27 & Jakarta EE 10 epic where you can find many other details and considerations that came up during our work.
A big thanks to Tobias Metzke-Bernstein for coordinating the development and to the Automation Platform team for all their efforts.
What is next?
For the next 7.20 release, we proceed with our journey for Jakarta EE 10. We plan to support SpringBoot 3 and Quarkus 3. Both environments are not fully implementing Jakarta EE 10, but are impacted by the namespace changes.
