Our team is planning to move a large monolithic application from an older Java EE environment to Jakarta EE 11. Given the namespace changes from 'javax' to 'jakarta' and the new cloud-native focus, what are the biggest hurdles we should expect? Is it worth going straight to a microservices architecture during this migration, or should we stay monolithic but modernized?
3 answers
The biggest hurdle remains the namespace migration. While tools like OpenRewrite or the Eclipse Transformer can automate much of the 'javax' to 'jakarta' refactoring, you still face challenges with third-party libraries that haven't updated their dependencies. Regarding your architecture, if your monolith is stable, I recommend a 'lift and reshape' approach. Move to Jakarta EE 11 first to gain access to modern APIs like Jakarta NoSQL and improved Concurrency, then identify specific bounded contexts to split into microservices later.
Have you considered the impact on your application server? Many older servers don't support the Jakarta EE 11 profile yet, so you might need to switch to WildFly or GlassFish.
Stick to the 'Strangler Fig' pattern. Migrate pieces of the monolith to Jakarta EE 11 microservices gradually instead of a big-bang migration. POSTED BY: Barbara Wilson DATE: 20-05-2025
Great point, Barbara. This allows for continuous delivery and reduces the risk of breaking the entire system during the transition to the new namespace.
Christopher, that's exactly why we are looking at Payara. It has great support for the latest Jakarta specs. The transition requires a full audit of our deployment descriptors, but the improved CDI (Contexts and Dependency Injection) 4.0 features in Jakarta EE 11 make the code much cleaner and more modular than the old EJB-heavy style we had.