Spring Boot or Jakarta EE – What’s Better?

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. 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 a deep understanding about Spring Boot that others may have. 

If you start from 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 me to easily connect my components and fasten my development. Both frameworks are now on the same level and fertilize each other.

Now I want to give you a short impression of why we, in the open-source project Imixs-Workflow, still trust in 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 several sub-projects each pluggable into each other. So it is itself a kind of framework and so we have to make some assumptions:

1. We do not know how one developer will use our framework
2. We do not know on which platform and architecture our framework will be used
3. We expect that our framework needs to be integrated into other frameworks like security, messaging platforms, or more.  

So wee needs 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 difference 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 catch 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 piece of code a developer can ‘observe’ and build his 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 an official specification document describing exactly how a CDI Event will work. And for Jakarta 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 is 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 to 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 a 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.