We’re considering removing support for legacy Java EE within Operaton to make the codebase more maintainable. I’m curious if anyone here is still using Camunda 7 in these older environments, as this change would affect compatibility with older Java EE versions as well as Spring 5 and Spring Boot 2.
Background on the Change
This proposed update removes shading for the jakarta-el library. Shading was causing issues in IDEs, with classes only available at build time rather than compile time, making testing difficult. Removing shading addresses these problems but would require dropping compatibility with older environments.
Some users have mentioned that if their entire stack is legacy, the Camunda dependency is likely the least of their issues, and they’re okay with the update. Others are either unaffected or are actively planning their migration to Java 21 and Jakarta EE, aligning with this change.
Implications
If we proceed, the next release would no longer support legacy Java EE or Spring 5/Spring Boot 2 environments. Given that OSS support for Spring Boot 2.7 ended in November 2023 (with commercial support ending in 2026), we must decide whether we want to align with OSS timelines or commercial LTS support contracts.
Next Steps
To make the project more accessible for new contributors, we’re inclined to drop legacy support but welcome further input from the community. If this is merged, we’ll be sure to label it as a “breaking change” and document it clearly in the release notes and migration guides.
Would love to hear everyone’s thoughts! Would this change affect your use case, or do you see this as a positive step for Operaton’s future development?
Cut the lines, do the breaking changes as early as possible. I do know the spring boot integration very well () and with this there is plenty of room for improvement.
I think it is also a burden for C7 that this legacy is supported. But they can’t that easily drop support, as breaking changes for C7 are likely unwanted.
Which software is also EOL that is currently in? Do you think we should get rid of any javax dependency? This would make things easier again.
I think the critical part are all javax.* API which are exposed in interfaces which are embedded into runtimes like spring or jakarta. Internal use of the javax.* API should be replaceable withot any side effects.
Another point of interest would be support for several application servers, e.g. some test suites für Application Servers are executed against the Java EE 6 API still if I remember this correctly
Honestly, I’m not really sure how this change impacts our applications. But from what was said, it looks like part of our apps will definitely be affected.
SO, all of our applications use the Camunda Engine embedded in their architecture and integrate with it through Spring Libraries (org.camunda.bpm:camunda-bom). Most of the applications are in Java 11 and Camunda 7.14 (those may be impacted) but we are migrating our stack to Java 22 and Camunda 7.21. So, the new stack will not be affected at all. Am I right?
@utelemaco Operaton requires at least Java 17 and is on a database schema and functional level of C7 version 7.22. Our aim is to be able to migrate from any C7 version up to 7.24. So when you upgrade to Java 22 and C7 7.21 now, you will be able to migrate it to Operaton later.
If you’re diving into the codebase, pull requests that help with some housekeeping—specifically, removing Spring 5 and Java EE would be greatly appreciated!
It’s a great opportunity to streamline things and pave the way for a cleaner, more modern stack. Every contribution, no matter how small, makes a big difference.
) and with this there is plenty of room for improvement.
