Jakarta EE gives a lot of options. It evolved.

Running an app server for a long time and redeploy apps to it is just one of them. To be honest, rarely used nowadays.

Many Jakarta EE products support:

* deploying apps on startup, just like Tomcat * bundling the server into a self-contained app, just like what SpringBoot does with Tomcat * running an app from command line, which Tomcat doesn't support - you have to drop the app into a predefined directory, SpringBoot doesn't support it either - the only option is to bundle the app and the server together during build

Some app servers are very lean, start in seconds, just like SpringBoot. Yeah, Tomcat starts faster, but only with a small app. If you add more libraries, you'd likely get to the same startup speed as SpringBoot or Embedded GlassFish.

I think the perception that JEE means big app servers where you deploy multiple apps and rarely restart the server, is very outdated. Nobody really uses Jakarta EE like that anymore. In fact, Jakarta EE is just APIs, the implementation can vary. Quarkus and Embedded GlassFish are perfect examples. Quarkus, although not fully Jakarta EE, can even build apps to native binaries. And Embedded GlassFish can run the same apps designed to run on app servers, on command line, without any installation of an app server.

And this makes the entire application server and Servlet model the wrong abstraction. Microprofile simplifies things, but in the end I feel Java EE is just pushing the wrong abstractions here. Cloud native microservices are meant to be small, and receive their "cloud native dependency injection" through standard Unix interfaces like environment variables standard input and output, command line arguments and sometimes files. Cloud native apps are close in spirit to twelve-factor applications (which is a stricter rendition of that).

Jakarta EE, even with its latest updates, comes from a different world. Standardized library API with interchangeable implementations that are injected by the application server. But wait! We flip the script by embedding the application server inside a fat JAR and shipping everything in a single docker/OCI container. A lot of the stuff that used to happen in the application server (load balancing, shared connection pooling, configuration, service discovery, service bus) happens now at the cloud infrastructure level.

You can still use a MicroProfile-based framework, and Quarkus (which is based on MicroProfile) is very popular nowadays, but once you went along with a certain framework, you're not very likely to replace it. Standardization was the selling point of Java EE in the past, but in the microservice world when you're only betting a smallish microservice on Framework X, people are not so concerned about putting all their eggs in one basket anymore.

The model made more sense before containers existed. Basically, Java tried to become a complete platform for application deployment, at a time when there weren’t many other good solutions to that.

However, the problem with that is that it requires writing everything in Java - heterogeneity breaks the model. A language-agnostic solution like containers was bound to win out, it’s just that nothing remotely close existed at the time.

Keep in mind a lot of this was developed even before VMs were commonplace. The first true, usable VMs for x86 were released in 1999, four years after Java’s debut.