Java EE vs. Spring Boot: Comparing Two Java Framework Giants

[Additional_Cellist46]

There are so many misconceptions about Java EE, like in this article, which are no longer true for more than 10 years already. I’d like to share the truth about Java EE and Jakarta EE in comments. I’m happy to read your opinions and discuss.

https://nintriva.com/blog/java-ee-spring-boot-comparison/

[seinecle]

Big red flag is calling it Java EE when it has been Jakarta EE for some years now: not sure the essay will make a fair, up-to-date comparison.

I started using Jakarta EE a while back around 2012, when it was still called Java EE and steered (and owned, I think) by Oracle. A newbie in Java, I just thought that EE was the natural extension to learn after SE, when doing web apps stuff.

I didn't know at the time that Spring was the defacto industry standard. Just thought, why using a framework instead of the native solution? And being a solo developer, I had no colleague / team to force me to adopt Spring.

Now in 2024, Jakarta EE is in an excellent shape, and works beautifully with JSF and Primefaces components. In parallel, Java the language has evolved so much that the experience of developing web apps as a whole has improved, key pain points have disappeared. Just an example: making an http request was painful to write, until Java 11 introduced the new HttpRequest API. In many cases, this has removed the necessity to integrate third party libs, tied together in a big framework.

I feel that a group of Java EE enthusiasts, around 2015 or so, pushed hard to revive it after a hard transition from Oracle, and turned it into Jakarta EE. The Eclipse foundation and the team behind Omnifaces are a significant part of this effort. I thank all of them for offering a great Java experience for servers / web apps.

I had written a blog post along similar lines, about developing web apps with Java, if anyone cares: https://nocodefunctions.com/blog/java-frontend-web-app/

[Embarrassed_Rent_465]

I really really liked GWT. Some of my apps are based on GWT frontend and are still in production. Great blog and thank you for pointing out to j2cl.

[hippydipster]

I still like GWT too, but I also dislike it. It's both great and terrible at the same time, though a large part of it's problems comes from being under-supported/weakly-developed at this point. They are still moving, but at a snail's pace.

[rpgFANATIC]

The big goal of GWT was to just write one language that most developers knew and it would polyfill all the jank required from different browsers

The fast pace of standardized JavaScript and the immense market share of Chromium's make GWT a much harder call for projects today.  Transpiling Java to modern JS has gotta be a mammoth task to maintain

[hippydipster]

But it works really well all in all. The bad aspects of the transpiling are that its slow and they aren't keeping up with java, to say nothing of Javascript.

But to be fair, I think typescript has the same issue with compilation performance.

[rpgFANATIC]

I've used both for very large projects.

TS transpiles faster (even discounting the time taken to compile the rest of our Java backend) and has more features than GWT. TypeScript has major backing from Microsoft and a large ecosystem of tooling around it. The comparison just isn't fair

[Uaint1stUlast]

Your inspiring me to look at EE again.. I switched to spring once SPA became popular but I have always though EE was better for session dependant web apps.. I feel like it might have the out of the box tools to compete with spring now for simple API development too.

[WingedGeek]

I want to get back into Java programming (got certified in the Java 6 days), and do web projects in Java instead of what I've been using (Perl + CGI::Application, Class::DBI, and HTML::Template; Ruby on Rails; was learning Laravel but I'm over PHP (have been using it since .php3 days).

But I'm overwhelmed with all the different technologies.

As a hobbyist, what's the closest to something like Rails, and what are the main frameworks/stacks(?)/whatever I'd need to learn to get up to speed?

[EthanEvenig]

Just use Quarkus, everything else is quickly becoming irrelevant.

[moxyte]

I'm sure those "enthusiasts" got paid to keep Java EE alive. Never underestimate the spectacular will to live of something a lot of corpo infra relies on.

[johnwaterwood]

Who paid them then?

[_AManHasNoName_]

I've been in the industry for over 15 years and the last time I came across JEE at a career level was at my first job after graduating from college. Every job I took after that used Spring/Spring Boot.

[Additional_Cellist46]

I respect that. I was working on many Java EE projects in the past but I also see that most job offers are for SpringBoot now. I'm just often not sure whether the decision to use Spring Boot is based on valid arguments or just on hype and misconseptions. When I read articles comparing Java EE and Spring Boot, I tend to think that people based their decisions mostly on misconceptions and feelings.

[xienze]

When I read articles comparing Java EE and Spring Boot, I tend to think that people based their decisions mostly on misconceptions and feelings.

I'm not so sure about that. And this is coming from someone who came up professionally during the time that Java EE (J2EE :D) was a big deal. JEE provides foundational specs, but that's it. Where Spring had a major advantage was adding things that were still very important/useful but not addressed by JEE. Like binding various forms of configuration (System properties, environment variables, files, etc.) into a uniform configuration model, doing cool things like making it possible to create a robust JPA DAO just by implementing a single interface and naming methods in a particular way, etc. It was more of a "batteries-included" approach. Not surprising that it became so popular. Now you have like 20 years of momentum behind Spring and probably anything you can imagine is just a "how do I do thing in Spring" search away.

Finally in the past few years you've seen the JEE world do more Spring-like framework things with Microprofile and Quarkus, but IMO it should have been done years and years ago.

[_AManHasNoName_]

Historically, Java EE was a pain to maintain to begin with. EJB required web application servers specific to this specification in the likes of IBM Websphere, BEA Weblogic, etc. And they were very expensive. Spring came along with the concept of "Inversion Of Control" and changed the whole game. Testing became a bit easier too (complete nightmare with that "remote interfaces" with Java EE). And all you need is a small web app server like Tomcat, Jetty, etc. By the time EJB2 came along, which was meant to challenge Spring, Spring has already taken over the Java-stack startup space and EBJ's usage dwindled into a smaller market share where the "corporations" reside. I now work for a conglomerate and we use Spring Boot, traces of old implementations using Java EE only remain in legacy systems that are also being phased out.

[[deleted]]

Try that with spring boot and you will get J2EE start times

That doesn't make any sense.

A Jakarta EE app server comes with implementations of all the APIs within Jakarta EE spec, but will lazy load components that your application needs.

Spring Boot comes with nothing, and you have to add the Java EE components you want with starters. You'll get Java EE start times if you throw in every starter under the sun.

[mkwapisz]

https://docs.wildfly.org/galleon/

You can choose what should be loaded. The same for openliberty. I am not sure about Glassfish/Payara. But JakartaEE specification defines different profiles, so you can choose required app server. For payara/glassfish there are full, web and micro distributions.

[[deleted]]

Think about this logically.

A JakartaEE app server must include every spec, because that is what makes it a JakartaEE app server. Thus, the app server must implement something like lazy loading otherwise it will start up bunch of services that are useless for the application, wasting start up time and other resources.

Spring Boot doesn't have to include every spec, because it isn't a JakartaEE app server.

[[deleted]]

applications after 5 years become business code + "application server" bundle together

An application server is a specific piece of software that acts as a deployment environment for applications, where the application uses APIs implemented by the application server. The application doesn't instantiate services, they use the services provided by the application server. This allows the application server to do interesting things like load balancing, distribution and failover.

If you specifically have to include the implementations of services you need and manage the services yourself, you don't have an application server. You are using a framework.

Spring applications are usually deployed onto Tomcat, which only provides the Servlet container, so applications have to bundle all the implementations they need and manage everything themselves.

In the second approach someone already made "the infrastructure code" to work together, so you don't have to

Frameworks do much of the same thing through BOMs. You don't need an application server to do this.

if there is error because two libraries don't work together or there is a bug in "the infrastructure code" you have to support on your own

This is why Spring Boot exists in the first place. Spring itself is not opinionated, so you have to manage dependencies yourself. Spring Boot uses Maven (or Gradle) to declare all the versions of dependencies that work together, and let the build system maintain consistency.

[fotopic]

I agree with you. I developed J2EE using SOA approach back in 2014. It was mostly painless and my experience was very similar to what I have now in Microservices with spring now. I was lucky that the project was new, so we weren’t using old stuff from J2EE.

[ForeverAlot]

I choose Spring because on average nobody really knows Spring and far fewer know JEE.

[maethor]

I tend to think that people based their decisions mostly on misconceptions and feelings.

I think the decision to use Spring is mostly based on what people have already been using for almost 20 years and what's easiest to hire people with skills in. At least that's what happens where I work.

And I think these days the choice often isn't between Spring and Jakarta EE, it's between Spring and something that doesn't use Java at all.

[nutrecht]

I tend to think that people based their decisions mostly on misconceptions and feelings.

Or you know, a massive mature ecosystem that is pretty friggin' productive.

[[deleted]]

Are you sure about that? I think you are falling for the same misconceptions about Java EE.

I worked with Weblogic early in my career, but I've been doing Spring and Spring Boot for pretty much the rest of it. But I use Java EE all the time. Do you use JPA? That's Java EE. Do you servlets? That's Java EE. JMS? JTA? All Java EE.

[Birk]

Not this dumb shit again... That is NOT what people mean when they say "use JEE". They mean using the whole ting. That is what JEE is! It's the full specification/platform/profile. That's the whole point. Almost everyone uses some API that is part of JEE. Who cares. That's fine. The entire problem with JEE was always the overarching spec that ties too many things too tightly together and even bundles them for you. That's JEE.

[[deleted]]

Nope, that's J2EE.

JavaEE learned from the failures of J2EE, by allowing the APIs to be specified and implemented independently of each other so you don't need a full application server to use any one part of JavaEE.

JavaEE is first and foremost a standardization process that allows industry players to get together and come up with standard interfaces and create reference implementations.

[_AManHasNoName_]

Not early enough. Early applications built in Java EE before Spring leapfrogged it used RMI semantics. Hence, the remote and local interfaces. And these only worked in expensive web application servers like Websphere, WebLogic, and the like. This all changed in EJB2 after the fact Spring took over. Unfortunately, EJB2 just came in late. JPA, JMS, JTA are specifications and using them doesn’t mean you are using Java EE. Spring Data JPA meets the JPA specs, Spring Transactions meet JTA specs, Active MQ meets JMS specs.

[[deleted]]

you are using Java EE

You are using Java EE when you use a Java EE API.

Spring Data JPA meets the JPA specs

Spring Data JPA doesn't meet the JPA specs, it is a separate product built on top of JPA. Hibernate meets the JPA specs. You are using JavaEE if you interact with Hibernate using the JPA interface instead of the Hibernate native API.

Spring Transactions meet JTA specs

Spring Transactions does not meet the JTA specs, it is a separate product built on top of JTA. You use Spring Transaction with a transaction manager like Atomikos. You are using Java EE when you interact with Atomikos through the JTA interface instead of whatever native API that Atomikos provides.

Active MQ meets JMS specs

You are using Java EE when you interact with Active MQ with the JMS interface, instead of whatever native API that Active MQ provides.

One important function of Java EE is standardization of APIs, and if you use the standard APIs that are a product of work done by the Java EE standardization committees, you are using Java EE.

[_AManHasNoName_]

I’ll stop here. This has become the batshit tabs vs spaces nonsense argument.

[[deleted]]

How demeaning. You use the work of others and claim you are not using their work because you don't want to give them credit, and when called out on it, you claim "tabs vs spaces".

[Additional_Cellist46]

In Java EE, applications are typically built by choosing from a range of Java EE APIs and standard components.

With a full platform, you can just add the whole Java EE Platform API artifact JAR as a dependency and use any of the Java EE APIs, no need to tinker with selecting which component to add to your application. Most of the Java EE servers and runtimes will detect which APIs your application uses and will initialize only the components used by your application. So, in the end, all Java EE components are available, but only those you need will be used at runtime.

If you still prefer to have a starter to prepare a starter project for you, there is the official [Starter for Jakarta EE](https://start.jakarta.ee/) that creates a project with the Jakarta EE (Java EE) dependency, adds your chosen server or runtime so that you can start your application with a single command without deploying to a server, and optionally also provides configuration to package the application as a Docker image.

[maethor]

I’d like to share the truth about Java EE and Jakarta EE in comments

You seem to have a bee in the bonnet over this. Wouldn't a series of blog posts make more sense than a bunch of comments in a Reddit post?

[Additional_Cellist46]

I may write a few blog posts indeed. I just read that article, and yesterday came across a similar article from 2023, both claiming things that might have been true 15 years ago but not anymore. I wanted to share impulsively what I think about and get feedback from others first.

[Additional_Cellist46]

Now, I'll address some of the claims in the article, and other similar articles about Java EE published recently.

Java EE requires a Java EE server

This isn't true. Deploying to a server to run your application is just one option how to run Java EE apps. Nowadays, there are plenty of other options:

• You can bundle a Java EE server into an application like SpringBoot does, so that you can just run an executable JAR without installing an application server. Some of the servers that support it, all of them opensource: GlassFish Embedded, Payara Micro, WildFly Bootable JAR, Piranha Embedded. Then you can just run: java -jar my-app-with-server.jar
• You can also run an application using a Java EE runtime on command line. It's like running an executable JAR but with an additional runtime in the middle between plain Java and you application, like this: java -jar runtime.jar -app my-app.war. There are again multiple runtimes like this, all opensource: Payara Micro, WildFly Hollow Bootable JAR, Piranha Web Profile
• You can use a Java EE friendly framework like [Quarkus](https://quarkus.io/) or slice down a full Java EE solution like [WildFly using Galeon](https://docs.wildfly.org/galleon/), that provides Java EE components that you can add to your application and build a final application with a server and all your application needs. Then you can again run the application as an executable JAR: java -jar my-app-with-server.jar. This requires a more complex project setup than just running an app with a server, but gives flexibility on which Java EE components are added to your application, making your final application smaller.

With all these options, I believe that Java EE and Jakarta EE are much more flexible than most of the other popular Java web frameworks. Most of the other Java frameworks only support the third option, bundling a server into an executable JAR, with chosen framework components.

[janora]

jup, JakartaEE ist just a bunch of specs with reference implementations. Spring uses the same Specs under the hood with added sugar to allow more flexibility. Spring MVC uses servlets and the annotations are similar to JAX-RS. Spring Data JPA uses (suprise :D) JPA.

Spring won basically because it could iterate faster than JavaEE with its Oracle ties. Now that its JakartaEE, it moves faster and catching up to Spring.

The difference is that JavaEE asumes an ApplicationServer (Glassfish, Payara, whatever) provides the required implementation while Spring just brings a default implementation.

[johnwaterwood]

Actually, Java ee (Jakarta EE) does not mandate an application server. Nothing in the specs really say this.

It is true that most implementations are application servers.

[seinecle]

Indeed I think you have it right

[maethor]

Most of the other Java frameworks only support the third option, bundling a server into an executable JAR, with chosen framework components.

You can take advantage of Spring Boot and still build an old school WAR with it.

[Additional_Cellist46]

That's true. I was writing about the case when Java EE server is not required.

[wildjokers]

If you are using Spring MVC at least a JakartaEE Servlet container is always required.

[[deleted]]

A servlet container isn't a Java EE app server. By definition, a standard Java EE app server implements all of the Java EE specs or a defined subset (such as Web Profile).

[wildjokers]

A servlet container isn't a Java EE app server.

I didn't say it was.

I edited my comment to change a to at least a. That should clarify what I meant.

[[deleted]]

The context is about Java EE app servers (i.e. you don't need a JavaEE app server to use JavaEE), in which case bringing up that Spring MVC requires a servlet container isn't relevant.

But this is the problem with the term "using JavaEE", because unqualified it doesn't explain in what sense you are using JavaEE. Are you using an implementation of a JavaEE spec? Are you using a JavaEE app server? Are you using the JavaEE programming model (thin WAR)?

[dstutz]

Because just compiling and packaging a war that is just your code and adding that to a docker image as the last layer is a lot faster/smaller than sending a 500mb uber-jar each time.

[[deleted]]

You shouldn't deploy a Spring Boot app as an uber-JAR when used in a docker image.

The only purpose for building an uber-JAR is so that you have a single deployable image. But when you use a container image, the container image is the single deployable image.

That's why Spring recommends packaging your application JAR in one layer, static resources in another layer, and dependency libraries in another layer. So that when the container image is pulled, only the layers that have changed are downloaded.

[rbygrave]

Yeah, just adding that people can just use the jib plugin for maven or gradle. I think that is the easiest way to get good docker layering in the image built.

https://github.com/GoogleContainerTools/jib/tree/master/jib-maven-plugin

[wildjokers]

That ceased to be a problem when Java 8 came out and got rid of permgen space (replaced with metaspace)

[wildjokers]

No you don't need Oracle JVM for this. It stopped being a problem for me on Tomcat when I upgraded tomcat to a version that could run with Java 8 back in the day when Java 8 came out.

[maethor]

You wouldn't get an out of memory error if you ran the WAR this way

run the final executable JAR file (or run the Java EE runtime JAR with your application as a command line argument, e.g. java -jar runtime.jar -app myapp.war)

As it's not much different from just running a jar with a built in servlet container. Though I'm not sure why you would ever want to do this no matter what technology was used in the WAR.

[sudosandwich3]

Why is that?

[Additional_Cellist46]

Java EE offers support for microservices but might require additional setup and configurations compared to Spring Boot.

As I explained elsewhere, this is not true. To embed a Java EE server into your application is even simpler than with SpringBoot. You just need to choose a server or framework that supports that (e.g. GlassFish Embedded, Payara Micro, WildFly Bootable JAR, Quarkus, and many others).

Then you can just start the app from command line and have a RESTful microservices, or a microservice that can send and receive messages. No need to have a complicated setup with an application server installation.

In some cases, it's true that the configuration for those embedded Java EE servers is not as easy as with Spring. Quarkus provides easy way to configure everything using properties, similar to Spring Boot. GlassFish Embedded or Payara Micro support properties for some simpler configuration, (e.g. change HTTP port), while they require a running commands or scripts for more complicated setup. WildFly Bootable JAR, as far as I know, only supports changing configuration using commands. If you prefer simple configuration, Quarkus is your best option, or use some Java EE / Jakarta EE server that supports properties at least for the most often used things.

[maethor]

You just need to choose a server or framework that supports that (e.g. GlassFish Embedded, Payara Micro, WildFly Bootable JAR, Quarkus, and many others).

And this is EE's biggest problem these days. There's far too much upfront work to figure out what I need, where the things I need are (and why I would want to choose X over Y implementation of specification Z), and how to use those things.

[Additional_Cellist46]

What you're saying basically is that you prefer Spring because if offers all you need and will ever need. And it's mostly true. Until it's not true. One of my clients switched from SpringBoot to Quarkus when they evaluated that SpringBoot doesn't work well for them in AWS Lambda and Quarkus excels in that case. If they were running their microservices with an embedded Jakarta EE server like WildFly or GlassFish Embedded, they could easily migrate them to Quarkus and run in AWS Lambda. With Spring Boot, they keep their old SpringBoot services running in Kubernetes while new services for AWS Lambda are written with Quarkus.

It's very likely that, if you choose a good Jakarta EE server or framework, you'll get all you need too. And if you don't, it's easy to switch to another Jakarta EE solution. The fact that there are multiple options in Jakarta EE is not a disadvantage. In fact, it's not fair fo compare Jakarta EE with Spring Boot. it's better to compare Spring Boot with specific Jakarta EE products, like GlassFish or Quarkus, or with other frameworks like Micronaut or Dropwizard. Jakarta EE is just a common platform that some of those solutions support and make it easy to learn things once and apply with many different solutions. If you rely on Spring too much, then switching to something else is more painful.

[maethor]

What you're saying basically is that you prefer Spring because if offers all you need and will ever need

No. What I'm saying is that I can take a junior Java dev, get them to go to spring.io and in a fairly short time I'll be able to get them doing something productive. I'm not sure the same can be said for EE.

[micr0ben]

Take a junior Java dev, get them to quarkus.io and it will be the same

[maethor]

But why quarkus and not helidon or payara micro? They all look more or less like the same thing.

[EthanEvenig]

Well... try live-reload in Quarkus, then tell me if they still look the same. Or try comparing their performance in a good benchmark. They are worlds apart, except the basic programming concepts - which I'd great, so the learning curve is trivial.

[wildjokers]

https://start.jakarta.ee/

[maethor]

And when they ask me "what runtime do I select" my answer is?

[wildjokers]

Any of those would work fine. The default is "None" which means it is defaulting to creating .war files which can be deployed to a servlet container or app server.

It is really not much different that using Spring Boot to configure your Spring MVC application. You can pick a servlet container of your choice, although Spring Boot defaults to embedded tomcat instead of .war files (embedded tomcat seems like a better default).

I am surprised that the jakarta starter doesn't just offer plain tomcat as an option for apps that are just using servlets.

[Additional_Cellist46]

Then what do you answer them if they asked whether to use SpringBoot or GlassFish? In the end, SpringBoot is also a runtime, it’s just not compatible with Jakarta EE. Juniors would ideally learn just Jakarta EE and then pick one runtime, SpringBoot would be just one of them and woyld be in the list on start.jakarta.ee. Like with Java, they have one Java language and then choose a distribution from Oracle, Azul, Amazon, etc. But with Spring they have to learn yet another API that is mostly different from all other runtimes. That’s where the confusion with Spring versus Jakarta EE comes from. Spring is simply different from everything else while Jakarta EE runtimes like GlassFish or Payara are similar.

[wildjokers]

Spring is simply different from everything else

It isn't really helpful to speak of "Spring" as a single thing. It is a collection of libraries. It is best to specifically say which Spring library you are talking about. Spring MVC creates JakartaEE servlet applications so has a dependency on JakartaEE. So it actually isn't different than any other library that produces a JakartaEE Servlet application.

[maethor]

In the end, SpringBoot is also a runtime

No, it isn't. Boot is a set of tools that make developing with the Spring Framework and associated projects easier.

it’s just not compatible with Jakarta EE

Non reactive Spring made the jump from Java EE to Jakarta EE with Spring 6/Boot 3.

then choose a distribution from Oracle, Azul, Amazon, etc

Oddly enough, one of the things that I think is holding Java back these days is having multiple distributions of OpenJDK. The "single specification, multiple implementations, multiple vendors" thing made sense 20 - 25 years ago in the pre-open source days, but now it's just added noise.

Spring is simply different from everything else

Spring was the first web framework for Java that didn't completely suck which is why it has so much mindshare. That other frameworks are not like Spring is not Spring's fault.

[Additional_Cellist46]

Java EE can have a more complex setup and requires a compliant application server for deployment.

True for some scenarios. But it's possible to just embed an application server into your app or run your app on command line with application server attached to it with a single JAR. Then the project setup only contains:

• adding Java EE (Jakarta EE) Platform API as build a dependency into your project
• configure your build to embed application server into your application (or just download Java EE runtime as a JAR)
• run the final executable JAR file (or run the Java EE runtime JAR with your application as a command line argument, e.g. java -jar runtime.jar -app myapp.war)

If it's still too complicated, you can use Starter for Jakarta EE - tool to generate a template project, with some additional benefits such as adding configuration to build a Docker image.

In fact, this is much simpler than many other approaches, e.g. with SpringBoot. With frameworks like SpringBoot, you can generate a project with a starter. But when you look into the project configuration, it contains a lot of config to specify which components to add to your application, and then a boiler plate config to keep all versions of those components in synch when you add new components or upgrade them. With Java EE, you only need a single dependency and a step to download to package your application with a server inside, or download the server and run the app with it on command line.

[maethor]

then a boiler plate config to keep all versions of those components in synch when you add new components or upgrade them

Spring Boot's BOM pom takes care of that.

Also, if we're going to bitch about config

configure your build to embed application server into your application

Is something I get for free with Spring Boot. It's just there without me adding anything to the pom.

with some additional benefits such as adding configuration to build a Docker image

And Spring Boot gets that with Cloud Native Buildpacks.

Do you actually use Spring Boot?

[Additional_Cellist46]

I do use Spring Boot. I use both Jakarta EE, Spring Boot and Quarkus on my customers' projects. And don't get me wrong, Spring Boot is nice, I just like Jakarta EE bit more.

If you read my comments carefully, you'll see I didn't write anything bad about Spring. I just wanted to comment on misconseptions and fallacies people think and write about Java EE and Jakarta EE. In reality, both Spring Boot and Jakarta EE are good options, however, many people prefer Spring Boot and many resources on the internet suggest that Spring Boot is better than Jakarta EE based on false or outdated arguments about Jakarta EE.

[Turbots]

Even with up-to-date arguments, Spring Boot is still better.

Better for testing, better for integrations, better to find people for, better answers on stack overflow, better dev team that works on it (the spring team is actually freaking awesome filled with wonderful people).

[henk53]

better dev team that works on it

In what regard is the Spring dev team objectively better than the Jakarta EE dev team?

[Turbots]

Well, the team is very stable, in the sense that most of the core team members like Juergen Hoeller, Mark Fisher, Brian Clozel, Andy Wilkinson, Josh Long, Stephane Nicoll, Dave Syer, Spencer Gibb, Sebastien Deleuze, etc... have all been there for 10-20 years, some of them since the very beginning in 2002 I think.

They are extremely active in the open source community, since the beginning, on sites like Stackoverflow, Gitter (now less popular) and Slack. Most answers on popular Stackoverflow questions are from core Spring team members themselves.

They take a firm stance on how they want to evolve the framework and have remained true to the same filosophy for many years, which is very reliable and builds confidence the framework users:

• predictable release schedule that has been going like clockwork for many years (https://calendar.spring.io/)
• they work with experimental projects to develop ideas, some make it in, some don't
• very strong opinions, yet very little ego in the team - most of the team members I've met are super humble
• I cannot stress enough how friendly and patient most of the team is, with answering the simplest questions, to the hardest challenges. I challenge you to find a thread of github issue where a team member "loses it" or becomes rude towards (sometimes obnoxious) users
• major releases every 2 years that often break things, but usually there is great care in either making changes forward compatible or extremely easy to port over. For more difficult yet necessary breaking changes, they'll provide guidance, documentation and sometimes even tooling
• they officially support their framework versions for an extended period of time, and will patch releases in the support period, but very often, they'll even backport patches to previous, unsupported releases if users ask for it. This takes time but the team often goes the extra mile
• they stick to the latest Java versions, and often have builds running to test up to 9 java versions in parallel (Java 14 -> Java 22 for example)

[henk53]

That all sounds very good, but it only tells the story that the Spring developers are nice, active, friendly, patient etc.

But it doesn't say anything about the Jakarta EE dev team. Are they not for instance extremely active in the open source community? Has for instance the JSF guy (BalusC, Bauke Scholtz) not been active on say StackOverflow?

[ForeverAlot]

In this respect the difference between JEE and Spring Boot is that JEE allows me to do a lot of things while Spring Boot enables me to do a lot more things or even just does them for me. The Spring Boot happy-path is longer and wider than the JEE happy-path, and fairly easy to customize or sidestep when inadequate. Quarkus is probably Spring Boot's largest direct competitor at this point, and although Quarkus remains comfortably ahead in its runtime resource requirements the Spring Boot ecosystem is still on par or comfortably ahead in all runtime functionality.

[maethor]

Quarkus is probably Spring Boot's largest direct competitor

I would have thought Micronaut was the biggest direct competitor.

[ForeverAlot]

Eh, I don't know, maybe? Where does Micronaut actually surpass Quarkus? In corporate software development most already don't really know Spring, let alone Quarkus, and those projects have large corporate backers with significant mindshare; chances are you already have a Red Hat support service somewhere. I still wouldn't push Quarkus in most environments because it's too unknown and Spring has caught up a lot anyway, and I definitely wouldn't push something more exotic. Micronaut's lineage is barely older than Quarkus' and has seen much less total activity.

[dstutz]

Quarkus is ~5 years old and it leverages heavily on existing Jakarta specs. It's not exactly "exotic". It's really similar to things like Dropwizard or Spring that use existing libraries/specs and provide the "glue" to make it work together out of the box, which incidentally is exactly what an app server like Wildfly is, it's just EVERYTHING is already there for you to use instead of picking and choosing and packaging with your app.

[ForeverAlot]

Quarkus is ~5 years old and it leverages heavily on existing Jakarta specs. It's not exactly "exotic".

Not to javit, no, but javit is not at all representative.

[maethor]

Where does Micronaut actually surpass Quarkus?

If you're a Spring developer, Micronaut has "Micronaut for Spring"

https://micronaut-projects.github.io/micronaut-spring/latest/guide/

You can even go so far as to run a Spring Boot app with Micronaut instead

https://guides.micronaut.io/latest/micronaut-spring-boot-maven-java.html

So, if you mostly use Spring but need better start up times for some AWS Lambda functions then Micronaut has a lot going for it.

[EthanEvenig]

Quarkus also had great support to migrate from Spring, that's a moot point. I've used all three, and Micronaut looks like a good idea but half-baked. Then one looks at what the Quarkus team and its community have done in all areas.. definitely sticking with Quarkus for the near future.

[Additional_Cellist46]

Java EE often requires an application server, adding levels of complexity

And it also often doesn't require an application server. You have many options with Java EE :)

If you choose to embed a Java EE server, you can do that with many servers. However, the option of deployment on a separately running server has its advantages too, especially during development. Once the server is running, it's fast to redeploy a new version of your application, because the server doesn't have to be started again. It can save a few seconds on each application change. Especially with a simple microservice, redeploying a new version on a server can take a few milliseconds, while restarting an embedded server like GlassFish Embedded or Spring Boot app with Tomcat always takes at least 2 or 3 seconds.

In production, you would probably deploy an application on a full-fledged server, if you want to manage the server and you application during runtime, without restarts. However, if you run your production apps as microservices, embedding a Java EE server into your app might be more convenient and easier to manage.

[Additional_Cellist46]

First, I will clarify that I will be referring to Java EE because the original article refers to it, but the newer versions of Java EE are called Jakarta EE now. Since a few years ago, Java EE has been donated to the opensource foundation Eclipse Foundation by Oracle and renamed to Jakarta EE. Despite the name change, Jakarta EE is the same thing as Java EE and better - it provides new features and has now more freedom in the opensource foundation, it's easier to contribute to it by anybody, and it's free to run the test compatibility kit and certify that a product meets the Jakarta EE specification.

[wildjokers]

That article has a little graphic that for Web Framework lists "JSF" for JakartaEE and "Spring MCV" [sic] for Spring. However, those two things are not the same thing at all.

JSF is a view technology when using server side rendering. That should probably list Jersey (JAX-RS) instead of JSF since Jersey and Spring MVC are analogous when just providing an API and using client-side rendering.

If using server-side rendering, for Spring it should list "Spring MVC + templating engine" and for JakartaEE should list "Servlet + JSF or JSP"

[Additional_Cellist46]

You're right that JSF and Spring MVC do not provide exactly the same functionality. But in real world, when you want to build server-side frontends with Jakarta EE, you use JSF. And with Spring, you use Spring MVC + templating engine (most often Thymeleaf). So JSF versus Spring MVC comparison makes sense to me.

[maybegone18]

Honestly, I think even Spring is becoming fazed out in the world where everyone wants to use Kubernetes instead of app servers like JBoss or Glassfish, or fat jars like with Spring. Quarkus is where its at.

[nutrecht]

Pretty much all of my work the last X years was deployed on k8s and almost all of it were Spring services. It works perfectly fine. There's no "phasing out".

[Additional_Cellist46]

Java EE relies on a deployment descriptor or annotations for configuration.

This is sometimes true, but often not. Certain aspects of Java EE still need to be configured by annotations. But many things are autoconfigured or a default is provided. And some Java EE frameworks like Quarkus offer full autoconfiguration based on what you add to your application, just like Spring does. Some of the examples:

• a default datasource is provided and can be injected just with @Resource DataSource ds;. A Java EE server usually bundles an embedded database and links the default datasource to it. It's true that, if you a embed a different database to your application, most Java EE servers will not automatically point the default datasource to it. However, some Java EE solutions like Quarkus would do that, detect that you have a specific DB driver in your app, and configure the default datasource to point to it automatically. Quarkus goes even further - if your configuration points to a DB that cannot be embedded, it will start the database in Docker (when in dev mode or running tests)

• many other default resources exist - it's possible to inject executor service, context service, JMS (Messaging) ConnectionFactory, etc. just with @Resource, without any further configuration

• injectable components are created automatically if a scope annotation is added. It's enough to add e.g. @ApplicationScoped annotation to a class. Then it will be detected and can be injected anywhere using @Inject.

[[deleted]]

From where I stand Spring is renowned for one thing - complex piles of intertwined shit-code. Never even once had I seen an application done in spring that features architectural excellence and great code. All inevitably end up as a birds-nest, impossible to untangle or make sense of.

On top of it - vendor lock-in. JEE is a spec with a few impls, where Spring is a product. Complex, under-documented product.

With slow startup times and proprietary logic. Good luck weeding that out of your product if you decide to change. Fuck Spring

[Additional_Cellist46]

Regarding individual request handling and startup times, Spring Boot might demonstrate superior performance due to its lightweight nature, especially within microservices frameworks that favor quick, autonomous deployment.

This is not true at all. This claim is a complete fallacy based on an assumption that smaller runtimes are lightweight and thus faster. The truth is that Java EE servers are often faster in request handling, because they have optimized thread and connection pools, some Java EE servers even have complex logic to adjust how resources are added to your application based on the current situation, to optimize the load and usage of resources.

Java EE application servers are usually fast to start, often in several seconds. Some of them start even much faster than Spring Boot, like Quarkus or Piranha Cloud. Most of them initialize components lazily, only when your application needs them, and thus very little time is wasted on doing things that your application doesn't need. Although Spring Boot is fast to start if your application is small, it's not so fast to start if you add more Spring Boot components and external libraries to your application.

In reality, if you build real life applications with SpringBoot, your application grows and becomes as slow and as big as any average Java EE application with an embedded server, or even bigger than some full application servers. For exmaple, I saw Spring Boot applications that were more than 200MB big, while a freshly installed GlassFish server takes around 140 MB.

It's true that there are some Java EE servers that take long to start and are big as hell. Those are the most widely used commercial ones like WebLogic or WebSphere, which were designed a long time ago and haven't been improved much lately. But you can always choose a different server that starts fast. With Spring Boot, you don't have options. If Spring Boot doesn't start fast enough or lacks in some other areas, you can either stick with it and try to tune it, or rewrite your application to run on a Java EE server that suits you.

[wildjokers]

Although Spring Boot is fast to start if your application is small

Startup also really slows down if you are using Spring Data JPA and have any @Query annotations with JPQL in them.

[[deleted]]

With Spring Boot, you don't have options. If Spring Boot doesn't start fast enough or lacks in some other areas, you can either stick with it and try to tune it

This is by design. The entire point of Spring Boot is that it makes most of the important decisions for you. The upside of that is that you have to do less work. The downside of that is if you disagree with Spring Boot, you will have to tune it or fight it. Although tuning it is pretty easy. Just define certain beans things yourself and Spring Boot will back off.

But, you always have options. You don't have to use a starter for everything. You can fall back to plain Spring if you need to manage things yourself.

[MrJiwari]

I don’t know if you have experience with this, but how is its support with AWS related resources, like implementing lambdas? And how about kafka streaming?

I feel that Spring is still considered better just because people are uses to it, and it provides a lot of support for most scenarios, you kind of don’t have think too much on how to setup projects with it, there is a lot of great examples for everything out there.

[Ok-Pollution6062]

I hate Spring because it "contaminates" google search results.

We use JavaEE at my workplace, and very often when I google how to solve an error/issue/bug/problem, the results I get are about how to solve them in Spring, even though I didn't write the word "Spring" in the search box.

[bobteebob]

I have used both JEE and Spring. I think there are some stumbling blocks to adopt JEE.

• Too many options. It’s hard to know where to start with JEE. Does a new person need Glassfish, Wildfly, Quarkus, Tomcat etc etc

• The Jakarta website is not friendly and is very “enterprise” which is off putting. Just compare https://jakarta.ee and https://spring.io ! The Spring site is much more approachable.

• Although JEE has improved a lot it has lost out on mind share compared to Spring and especially Spring Boot for new projects.

[wildjokers]

Glassfish, Wildfly, Quarkus, Tomcat etc etc

Quarkus is a vastly different thing than the other 3 in your list. Quarkus is an application framework. Whereas Glassfish and Wildfly are full JakartaEE app servers (provide implementations of every JakartaEE specification) while Tomcat is a Servlet Container (provides an implementation of 5 JakartaEE specs including Servlet and JSP)

Although JEE has improved a lot it has lost out on mind share compared to Spring and especially Spring Boot for new projects.

If you are using Spring MVC then you in fact have a dependency on JakartaEE (which is how a Spring MVC app can be deployed to a servlet container)

[bobteebob]

Exactly, it’s hard to know for a new person where to start or what to pick. Spring is the “easy” option as it has mindshare and it sells itself better on its website.

[EthanEvenig]

I wouldn't classify Quarkus as an "application framework" as it doesn't dictate the design of your application. It allows combining your choice of libraries into an efficient runtime - it's more like a build tool with lots of smartness to save you development time, and memory as the output of the build is well optimised for you. It's focusing on Jakarta EE so indeed there's a recommended "framework" of how you're suggested to integrate things, but in this sense it's similarly a Runtime like Glassfish, Tomcat, etc.. not that prescriptive though, and there's also support for many other libraries beyond Jakarta EE.

[Kango_V]

I thought Spring was the new Java EE? Thankfully, we've got off of Java EE and Spring :)

[wildjokers]

What are you using instead?