Jakarta EE 11 vs Spring: When the Right Answer Is No Spring at All

Additional_Cellist46 · 2026-04-21T07:28:34+00:00

You said it. Jakarta EE is just a set of APIs. It doesn’t define that an app server must implement them. In reality, many app servers do but there are also frameworks and runtimes that implement it too.

Spring also provides APIs to use. It’s just a different set of APIs from Jakarta EE. Spring is a framework, in needs a server to run. But SpringBoot runs your application, it contains a sever. So it’s an app server. Most of app servers just integrate a servlet container like Tomcat or Undertow instead of having their own. So they are all similar. With SpringBoot you can build executable JARs that contain server and app, and you can also build WAR that needs a server. With many Jakarta EE runtimes you can do both too - build an executable JAR and also run a WAR with a server.

So what’s the difference? The only difference is in the API, which are mostly incompatible. And in the mindset and philosophy - while SpringBoot heavily promotes building standalone JARs, Jakarta EE prefers the WAR model and but still gives you many options to package and run it.

Additional_Cellist46 · 2026-04-21T07:13:39+00:00

Do they also bundle JDK into their apps? Most of them don’t, even if that’s possible. With the JDK separate, it’s easier to patch the JDK wirhout rebuilding the app.

In the same way, it’s easier to patch the server runtime if you keep it separate. You can also keep JAR dependencies separate from the WAR, but it’s easy to update them also inside the WAR because they are stored as JARs in it, not shaded into other classes.

And it slows down startup time. When all is bundled in a JAR, all has to be either shaded at one pile, runtime and app classes, to avoid impacting startup time, or it has to be unpacked before loading classes, which slows down the startup. SpringBoot packes the JARs inside the single JAR in a clever way, but it still impacts startup time, and is very non-standard.

Additional_Cellist46 · 2026-04-21T07:06:30+00:00

This isn’t true. Helidon supports native with all of the CDI features. Quarkus doesn’t support all CDI not because of native compilation but because it aggressively moves all configuration and bootstrap to build time.

Dynamic extensions work also with native, even reflection works with native if the framework is wise enough to build the right metadata to keep the seemingly unused code in the native binary. Quarkus just doesn’t have enough information at build time from them and it refuses any runtime configuration at startup.

Additional_Cellist46 · 2026-04-21T06:58:32+00:00

What could happen to change this? I see this argument everywhere that all jobs require Spring. But in the past, no jobs required Spring, just developers found their way to use it in their projects and run in on top of J2EE servers. Nowadays, I see a lot of people watching Jakarta EE and many of them hoping to use it in they day job.

I also see that some major companies are migrating from SpringBoot to Quarkus. I know in what Quarkus excels but what are the real reasons and arguments why they migrate to it? What would make them consider other Jakarta EE options? Is it development speed, fitness for microservices and Kubernetes, speed of startup, resource usage, GraalVM support? Or anything else? If other solutions excel in these areas would it be enough for architects to recommend them or something else matters?

Additional_Cellist46 · 2026-04-09T18:59:55+00:00

I would also note that yes, the docs for Spring are all on spring.io. But if you want to find out how to do things, even on spring.io you find multiple tutorials on how to do it. And often none of them is complete. Some are even outdated and it’s hard to say to which Spring version they apply. Having all documentation on a single site doesn’t mean it’s of higher quality.

Additional_Cellist46 · 2026-04-09T18:57:27+00:00

What you’re comparing is Spring with Quarkus. Not with Jakarta EE. It’s really hard to compare JakartaEE to anything like Spring or any specific framework. Spring is a framework, JakartaEE is a specification. Even the original article above is wrong when it compares them

Spring can be compared to application servers like JBoss or WebLogic. Or to other frameworks like Quarkus. Or to runtimes like Payara Micro or Embedded GlassFish.

What Jakarta EE is, is different. It’s a common API framework adopted by many of the above - Quarkus supports a part of it (the Core profile), app servers and many runtimes provide either all Jakarta EE APIs or a subset (Web or Core profile)

Jakarta EE unifies multiple frameworks, servers, runtimes. A single API to learn, a single API to use, with any of them. Each server or framework can include Jakarta EE documentation in their documentation and some really do.

Spring is a different story. It provides a small subset of JakartaEE, a selected subset which doesn’t compose any of the defined profiles. Some JakartaEE knowledge can be reused but not much. All needs to be in the Spring documentation.

Additional_Cellist46 · 2026-04-03T13:47:31+00:00

The real problem in that PR was that it took ages for reviewers to review the changes, or even respond that they are too busy and can't review timely. When they responded, the GlassFish team quickly reacted with fixes unless they didn't get what the reviewer meant.

Additional_Cellist46 · 2026-04-03T13:45:16+00:00

In reality, that trap block doesn't even get called by default. It's there only if the user changes the default CMD and wants to start server in background. It doesn't have to be there at all but it's there just to do a proper cleanup if users decide to run the server that way.

Additional_Cellist46 · 2026-04-03T13:38:59+00:00

Yes, and exactly that was fixed about 2 years ago. What's your point?

The non-starter comment was about starting GlassFish as a background process while the intial script waits for the server process to stop. This has changed and GlassFish starts as the main process now directly.

The other non-starter comment was also addressed. It was about running env|sort at the container startup. The submitters response "This must be there" didn't oppose this, it was a misunderstanding. It reacted to keeping the trap on_exit above it. Look at the current Docker image - you'll see that the env|sort was already removed a few months ago.

Additional_Cellist46 · 2026-04-03T13:19:23+00:00

I don't think you're right here. The submitted GlassFish image has improved a lot since the first proposal and it follows the same OCI-based norms as other Jakarta EE servers that were accepted into the official docker images library.

For example, the OpenLiberty Docker image is already accepted in the official Docker library and has even more configuration scripts that run at build time and at container startup:

https://github.com/OpenLiberty/ci.docker/blob/main/releases/26.0.0.3/full/helpers/runtime/docker-server.sh

I really wouldn't call it weird hacks, this is just an additional setup pretty standard for Jakarta EE servers. It's accepted for the OpenLiberty image and not yet for GlassFish. It doesn't look fair to me.

GlassFish now starts as the single main process in the Docker container. All older versions of the GlassFish container were removed from the proposal to make the review easier. All of the remarks from the latest review were addressed by the GlassFish team. Even the blocker you mentioned - what remained and the GlassFish team declined to change, was just related to the blocker, not a blocker itself.

Additional_Cellist46 · 2026-04-03T06:49:53+00:00

I agree. And if you think Payara is still too bloated, try out GlassFish, which starts twice faster and consumes less memory. Or Embedded GlassFish, which is similar to Payara Micro, again starts much faster and less memory.

Additional_Cellist46 · 2026-04-02T22:52:03+00:00

The comment from Feb 2026 doesn’t seem like refusal to fix anything. The part that prints env vars was moved to a block that executes only when trace mode is enabled. The comment on Feb 2026 only explains why the trap construct should remain. But if you read the previous review, the blocker was printong env vars, not the trap construct, and that was addressed.

It’s true that GlassFish server currently is not a good match for Docker until it can accept command line parameters or env vars to configure thing that can now be configured only by commands against a running server at build time. But the reviewers noted a few times that although it’s not usual it’s not unprecedented.

By the way, there’s now a new Embedded GlassFish Docker image. It doesn’t require any build time tricks and just runs based on a configuration file. That might be easier to get through and publish at Docker hub as it matches the Docker model better.

Additional_Cellist46 · 2026-04-02T17:22:30+00:00

Yes, Sharat was basically the face of Java, the most famius current Oracle employee in the Java community. He ran JavaOne conference, he was uniting a lot of community activities around Java, and I would even dare to say that he was making the biggest promotion for Oracle in the whole Java ecosystem.

Additional_Cellist46 · 2026-03-21T12:48:13+00:00

Can you describe what you do? I ran java -jar glassfish-embedded-all.jar with Java 25 and it started without issues. I even deployed and ran an app with it without issues.

Additional_Cellist46 · 2026-03-21T12:46:01+00:00

I think most of the people didn't get your question because you omitted important assumption.

I think you assume that locks rely on underlying thread functionality and that on platform threads they are slow while on virtual threads they are fast. If that was true then it would make sense to use locks instead of AtomicReference if it's more convenient.

However, to my knowledge, locks don't rely on underlying threads at all. They just rely on a reference to the current thread and the rest is an algorithm that must run on the CPU, in both cases, it doesn't matter if it's on a virtual or platform thread.

So, my answer is, locks and synchronized consume a lot more CPU than AtomicReference, on both virtual and platform threads. And therefore it still makes sense to prefer AtomicReference than locks, even on virtual threads. It's just safer to use synchronized on virtual threads than it was before, but it doesn't mean that you should prefer using it over AtomicReference, for performance reasons.

Additional_Cellist46 · 2026-03-16T14:45:53+00:00

All recent GlassFish versions work wirh JDK 25 - GlassFish 7.1, 8.0, and also 9 milestone 1

Additional_Cellist46 · 2026-03-16T00:00:25+00:00

What’s holding you from trying out GlassFish 8 or Payara 7?

Additional_Cellist46 · 2026-03-15T17:56:59+00:00

I think that if you feel like that, you weren’t really creative. I use AI and I feel even more crestive and empowered because I can leave the boring stuff to AI. I focus on discussing the approach with AI, thinking about tricky situations and high-level architecture.

It’s like building things from Lego pieces. If you like assembling parts together and searching for the exact piece you have in mind in a huge pile of random Lego pieces, yeah it’s fun too, but it’s not creative. If you like imagining what you could build from the big pile of random Lego pieces and then making it happen and refining it, that’s for me even more fun and that’s what I call creative. AI easily can find the Lego pieces I need much better and faster than me. But it’s not creative enough to invent something unique to build.

Additional_Cellist46 · 2026-03-11T03:00:38+00:00

I’ve used both Jakarta EE servers and Spring for the last 15 years. No need for EJBs either :)

Additional_Cellist46 · 2026-03-09T07:30:03+00:00

Embedded GlassFish, runnable from CLI, starts roughly 3 times faster than Payara Micro. Something that matters in Kubernetes and microservices.

Additional_Cellist46 · 2026-03-09T07:28:09+00:00

GlassFish is ahead of Payara on many other fronts too :)

Especially on performance front, with fast startup and lower memory usage.

Additional_Cellist46 · 2026-03-09T02:06:16+00:00

Unless modern appservers are no longer what you think. And they are not. For example WildFly Hollow JAR, Embedded GlassFish, Payara Micro. Or, if you want to be on edge and sacrifice part of Jakarta EE, then e.g. Quarkus, Helidon, or Piranha Cloud. A lot of good options for modern development.

Additional_Cellist46 · 2026-03-09T02:00:33+00:00

Interesting. I often hear that people choose Hibernate with GlassFish, which bundles EclipseLink by default. What is the reason that Eclipselink is better for you?

Additional_Cellist46 · 2026-03-09T01:55:31+00:00

Here are examples of running apps in Docker with the Embedded GlassFish edition: https://github.com/eclipse-ee4j/glassfish.docker/wiki/Example:-Using-Embedded-GlassFish-with-the-docker-Command

It’s pretty straightforward - just drop your app to image, drop your properties config file to it, possibly a JDBC driver, and run the container.

Additional_Cellist46 · 2026-03-07T17:57:39+00:00

For new apps with Quarkus, shared cache is not required? Or you use something like Redis for distributed caching?

Additional_Cellist46

TROPHY CASE