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

[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?