Javax vs jakarta

Camunda origins from pre-Jakarta-times. This is also throughout the code base.

There are some modules that rely on the old javax namespace and sibling -jakarta modules. For example

  • engine-rest
  • engine-rest-jakarta

The transition from javax to jakarta is done with the Eclipse Transformer

These implicit modules cause dependency problems that makes development harder, see Tests not executable from IDE · Issue #84 · operaton/operaton · GitHub

Does Operaton needs to be backward compatible, or should it just move completely to Jakarta API?

1 Like

Thanks for bringing this up!

I was wondering, too, why the javax.el / jakarta.el classes are shaded. Usually one does this to prevent other versions on the classpath from breaking functionality, e.g. like it is done with Google Gson in the engine, too. The EL Api should not be affected by something like this, but I think they did this so they can interchange the javax.* and the jakarta.* packages internally, while not exposing either of them to the API?

The change was done here feat(engine): use Jakarta EL API for JUEL by tasso94 · Pull Request #3013 · camunda/camunda-bpm-platform · GitHub

An explanation is here: Add a proper dependency to the `jakarta.el` API to reduce maintenance efforts · Issue #2980 · camunda/camunda-bpm-platform · GitHub

I’m not an expert on this specific issue, but from my understanding, these javax classes have been marked as deprecated since JDK 9. It might be best to remove support for them altogether. This aligns with our decision to raise the minimum Java version and adhere to standard support timelines set by the upstream dependency projects.

I also think that this was done for compatibility reasons. In a “normal” project you could just add the new jakarta API as a dependency, but for older application servers (Wildfly, Weblogic, etc). this was not that easy, or would mess with the integration. I’m in favor of adjusting this and removing the javax.* support.

We need to keep in mind that the shaded classes are part of some modules API unfortunately, so this needs to be mentioned in a migration guide “Camunda → Operaton” and encoded in the planned OpenRewrite script, too.

I would argue that it‘s not an application problem, if the app-server is „old“ or outdated. Therefore I wouldn‘t use libraries just for those

I totally understand why C7 continues to support these older environments. My guess is that they have customers willing to pay for those extended “enterprise support lifecycles” For those customers, sticking with C7 or transitioning to C7-EE seems like the most logical choice.

That said, using outdated software under long-term support agreements tends to get increasingly expensive for enterprises.

But this cannot be in the scope of this project, we need to stick to standard support cycles with our limited resources.

2 Likes

Cutting these weak ropes is also a big chance for Operaton. We can more easily adjust to new standards and support modern environments. It helps to modernize the code base and shift it to the next level eventually. Customers who seek for a modern BPMN engine, especially in embedded and on-prem installations, will find in Operaton the product they can rely on.

4 Likes