Why is there no enterprise Java CMS based on Spring Framework or Spring Boot?
Introduction
Spring framework is fantastic. Most Java developers work with it at some point, and they all enjoy it. Spring provides good dependency injection and many other libraries/tooling (Spring Security, Spring Batch, Spring Boot, ..) to solve the typical problems developers face.
That said, when building a platform, Spring has important limitations, and they cannot be ignored or avoided. Most projects will never face such limitations, and this article shouldn’t be read as a pamphlet against Spring; it only covers the use case of platforms, specifically Content Management Systems (CMSs) and Digital Experience Platforms (DXP).
What is a platform anyway?
The term platform is often used without too much care. A platform is a software where third parties can deploy extensions, known as plugins, apps, or modules, depending on the vendor. Most CMS are platforms, for 2 reasons:
- Developers need to be able to deploy their custom templates and components
- A CMS sits in the middle of a rich ecosystem to manage digital experiences. It needs to integrate with analytics, DAM, CRM, Marketing Automation, SEO analysis, translation systems, consent management, etc.. For all these connectors, an apps/plugins mechanism is needed.
In other words, a good CMS is a good software to manage websites AND a good platform to manage plugins/apps/modules. When applied to the Java world, the ability to manage 3rd party modules implies specific technology choices.
“Isolation”, the underlying requirement of any good Java platform
When building a project using Spring framework, you use one Spring Context. Inside a Spring Context, there is only one classLoader available, meaning that only one version of a class can be loaded. This simple limitation is impossible to overcome and has strong consequences: The platform would always come with its own context, that you'd need to reuse; and if the platform vendor embeds some library, developers building modules/plugins will need to use the same version of that library. This would quickly become very hard to live with, especially during migrations
It is also possible to use several Spring Contexts within the same application, but then you'll face another issue: you won't be able to easily share objects/data between these contexts. So, if you need to reuse a service layer across different parts of your application, you won't be able to.
On the other hand, OSGi has been designed to provide that kind of flexibility. Unfortunately, Spring and OSGi can’t really work well together. There are some ways, but you’ll face issues and dead ends in the long run. For more information, you can read about OSGi's advantages in my article about Headless Java CMS.
About JPMS (Java Platform Module System) and Spring modulith
Other technologies are available for modularity in Java: JPMS (Java Platform Module System) and Spring modulith. Neither of these solutions provides the maturity and the flexibility of OSGi. Our understanding is that both of these are great for ensuring that your software code is split properly, but they don’t solve the specific use case of deploying custom code on a Java platform.
On Spring Boot: Yes, Spring Boot is very popular, and for good reasons. However, as it is based on Spring Framework, it is incompatible with OSGi. So you’ll either find a good, modular CMS OR a CMS based on Spring Boot, but you can’t have both.
Conclusion
Even though Spring is popular, while OSGi is more confidential, if you’re looking for a technology that supports embedding Java code that follows different lifecycles, then OSGi is the only way to go. Yes, OSGI has a steeper learning curve, (even though it's not as bad as what's written in many forums), but after many years of using it, we do confirm that the efforts are worth it.
