No – I don’t want to start a new flame war in which I put one framework above the other. Both, Spring Boot and Jakarta EE are great frameworks to build great modern Java applications. Some developers prefer this, others prefer that. Why is that? I think it’s often just because the one developer has collected more experience with Spring Boot, the other one with Java EE. These technologies are developing very fast and it is difficult to learn and be able to apply everything correctly. Basically it is a kind of protectionism that you put one over the other so that you don’t appear stupid and ignorant. But there is a certain noise around Spring Boot that gives the impression that Spring Boot would be the far better system.
I am personally working with Java EE since the beginning – 20 years ago! So – yes I know the one much better than the other and I don’t have the deep understanding about Spring Boot that others may have.
If you start form scratch with a new application or a microservice, Spring Boot is great because it gives you all you need and you can start within minutes. That’s fantastic. Java EE developers were always jealous of Spring Boot. Java EE caught up when it integrated CDI in 2013, which was invented originally by Spring and CDI was simply awesome. It allows you to easily connect components to each other and fasten your development. Both frameworks are now on the same level and fertilize each other.
OK – now I want to give you a short impression why we, in the open source project Imixs-Workflow, still trust on Java EE/Jakarta EE. As mentioned above in case you start developing a new application both frameworks are even. A Project like Imixs-Workflow is different. It is an open workflow engine with a number of sub projects each pluggable into each other. So it is itself a kind of framework an so we have to make some assumptions:
- We do not know how one developer will use our framework
- We do not know on which platform and architecture our framework will be used
- We expect that our framework needs to be integrated into other frameworks like security, messaging platforms or more.
So wee need a solid concept to open it in a way that the framework did not break other things or limit the developer in designing her application. We need a framework supported by different parties and maintained from different views. And this is in my eyes the main different between Spring Boot and Jakarta EE. The development of Jakarta EE is not only driven by one single company. It is a community consisting of individuals and big tech companies. And this is not a bad thing. You can be sure that your application will work for years and there will always be a comfortable solution to caught up with new technologies.
Let me show this in an example. If I want to extend my framework so that other developers can integrate easily I can define a CDI event. This is a tiny simple peace of code a developer can ‘observe’ and build his own extensions.
public void myFunction(@Observes org.imixs.workflow.engine.DocumentEvent event) {
... do something with this object ....
}This code will run on any application server and I can be sure a developer can adapt the Imixs-Workflow DocumentEvent in a clear and well documented way. There is a specification document describing exactly how a CDI Event will work. And for Jakarata EE you don’t need to bundle your application with a CDI library – you just work on the specification. Don’t get me wrong – CDI Events are also part of Spring Boot. But you can not assume that each Spring application integrates Events.
A similar example are cross-cutting functions like monitoring, metrics or configuration. With the project microprofile.io there is a lot for work being done in silence behind the scenes. Microprofile integrates into the Jakarta EE stack and is already part of all modern application servers. This means you can adapt such cross-cutting functions in your Jakarta EE application in a very easy way. For example in Imixs-Workflow we changed our configuration from only one central property file to microprofile-config. This means that Imixs-Workflow can now inject configuration values which can be provided in various ways.
@Inject
@ConfigProperty(name = "metrics.enabled", defaultValue = "false")
private boolean metricsEnabled;This config property for example can be provided from plain property files, environment variables, Kubernetes ConfigMaps or even with a project specific database configuration table. For a framework project like Imixs-Workflow this is an important aspect as we don’t know how the target application will look like. So we need to be open in those things.
You may now have the impression that I prefer Jakarta EE over Spring Boot. But again, that’s not the point. I want to point out that there are different targets in the development of an single application, a microservice or a framework. To ensure a very open architecture for a framework project like Imixs-Workflow, Jakarkara EE offers a broader and more in-depth specification. For many application projects or microservices, this may not be a valid argument to justify any additional training costs. So the argument remains valid to use the framework with which you have gained the most experience. But stay open when choosing your tools and avoid prejudices. Everything in the universe has its meaning.