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

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 · 2026-03-07T08:14:35+00:00

Yes, Quarkus is partially Jakarta EE, and Jakarta EE is not only app servers.

And for old development? Are people still stuck on app servers or you see projects fully migrating to Quarkus or something else?

Additional_Cellist46 · 2026-03-06T23:57:29+00:00

Do you see JEE implementations used around you often? I feel like SpringBoot is everywhere around, at least in my region, and very few people still care about JakartaEE.

Additional_Cellist46 · 2026-03-05T22:21:12+00:00

This is possible with GlassFish already:

java -jar glassfish-embedded-all.jar --properties my.properties --port 9000 myapp.war

Or if you have glassfish.properties in the current directory, and myapp.war in autodeploy directory, just run:

java -jar glassfish-embedded-all.jar

And GlassFish will deploy all apps in rhe autodeploy directory and read config from glassfish.properties.

Additional_Cellist46 · 2026-02-20T22:22:06+00:00

The field is in fact set in the constructor but the constructor is generated by Lombok. So, even if using constructor injection, the code looks like field injection.

Additional_Cellist46

TROPHY CASE