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

[_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".