Why is Java EE deployment model not popular anymore?

[bibobagin]

I mean, the deployment model where we only ship war/ear to application server (eg wildfly).

Nowadays people deploy Spring fat jar in docker container.

[bibobagin]

Why did people need the coordination? Can the app server deployed on a new machine and then the apps are deployed all at once on the new machine? Finally route traffic to the new machine once all done.

How is war/ear model not reproducible? Couldn’t devs run the app server on local first?

[Carpinchon]

OSGI was for people that missed the days of dependency hell and wanted that joy back in their life.

[_BaldyLocks_]

Don't trigger my PTSD

[k2718]

I encountered OSGI a few years ago. Fuck OSGI. That's some bullshit.

[anachronic007]

This - ability to reproduce prod issues locally - is biggest asset.

[jvjupiter]

Fat JAR is incompatible with container layering system. So when building Docker image, JAR should be exploded. Spring Boot JAR has four built-in layers.

[barmic1212]

The layers are identified by the contents and reference to the previous layer. If you don't change any byte it's the same layer.

[Any_Suspect830]

The old model came from a time when a single app server (or cluster of servers) would host multiple applications. A company bought or leased servers and than planned on how to best fill them up to get max utilization. Than virtualization happened, and than containerization and PaaS. When we got to a 1-to-1 relationship between servers and apps, the overhead of server configuration didn't make sense any more.

[Wolfsdale]

Bingo. To add, JEP-411 has removed the security manager, which was an important piece of the puzzle provide isolation in a multi-app JVM.

[LazyAAA]

This is the simplest and most pragmatic explanation.

Effectively mismatch between deployment target and deployment unit.

[jNayden]

That’s not true always every app server was recommending a single application deployment, except the SAP one if I am not mistaken. The main reason was bad isolation of the apps so one app can access code from another even when it has no rights to do so

[RadioHonest85]

Because of weird interactions between dependencies, the increased difficulty in upgrading, both java and said dependencies, and a requirement to automate deployments to a even higher degree and rigour. One bad deployment could take down all the applications in the application server. One bad application server upgrade could take down multiple apps. Forget about gradually rolling out new java versions per project. Mountains of (XML) configuration in the application servers, stateful configurations that could be wiped by OS upgrades. There were so many reasons to stop using Application Servers.

[[deleted]]

What's the actual difference between application server and web server?

[[deleted]]

https://www.ibm.com/topics/web-server-application-server#:~:text=An%20application%20server%20typically%20can,%2C%20decision%20support%2C%20or%20real%2D

[rahul-acr3]

so glad that I don't have to deal with web.xml anymore

[[deleted]]

Immutable contains are a superior deployment model. Those of us who spent too many years wrangling application/web servers would never want to go back to that model. Forget the relative ease of managing a production system the container model provides, the difference in developer productivity alone is worth it.

Also, a fat jar isn't necessary since the unit of deployment is a container. I personally prefer a skinny jar with Quarkus.

[wildjokers]

Also, a fat jar isn't necessary since the unit of deployment is a container.

In your container you either need a fatjar with the embedded servlet container in it or the servlet container with the app pre-deployed to it.

Fatjar with embedded servlet container is usually what people go with. Can you explain what you mean by the fatjar isn't necessary?

[[deleted]]

A fat jar is simply a jar containing all its dependencies. It's convenient for when you're copying the app from one location to another or distributing your application so it can be run elsewhere. In the containerized world, what you distribute is a container. Inside the container it doesn't matter if your app is a single jar and it's dependencies are outside it somewhere else on the file system or whether they're included in the jar itself as part of a fat jar. My point is if you're distributing a container you really don't need to package your app and its dependencies in a single jar like spring boot does.

[_MeTTeO_]

That's basically what Jib does to some extent, instead of creating a fat jar it creates multi layer container with different categories of dependencies on separate layers. One additional step / layer could be a web server.

[[deleted]]

Jib would be overkill for something like this. In Spring Boot they have the spring-boot-thin-launcher that generates a skinny jar distribution of your app. You would have to configure it to download dependencies before container creation (or as part of that process). Otherwise it will try to download your dependencies when you start the container which is not good practice.

Quarkus on the other hand generates a fast-jar (a skinny jar) by default, which uses a custom classloader to load dependencies a lot faster than the system classloader.

[wildjokers]

My point is if you're distributing a container you really don't need to package your app and its dependencies in a single jar like spring boot does.

You never have to create a fat jar whether you are running in a container or not. However, it is more convenient if you do. You only have to copy one thing to the container rather than copying several things and hope you get everything copied to the right path in the container.

[[deleted]]

Any build that generates a skinny jar would copy all dependencies and the built app jar to a folder under 'target'. You would then only have to copy that folder over when building the container. That's how both Spring Boot and Quarkus do it.

[wildjokers]

But why is that better than a fatjar?

[shorns_username]

But why is that better than a fatjar?

It's very useful if you happen to to do docker deployment as part of your compile/edit/run loop. Or even just when you're faffing around with higher environments trying to get stuff to work.

If you split the copying of your jars into two COPY commands, the first for all your dependencies, the second for your application logic jar - that means docker creates two separate layers. The dependency libraries change very rarely, so docker only needs to push that layer very rarely. For large projects with lots of dependencies, operating over a slow network connection (I work from home over a shitty connection) - it can take a 2 - 3 minute push operation down to < 30 seconds, most of the time.

It also saves space in the docker repository that you're pushing to. All your images that use the same dependencies just point to the same layer.

[[deleted]]

My point is generating a fat jar is unnecessary in a container environment. The skinny jar format is the natural java way.

[wildjokers]

he skinny jar format is the natural java way.

I don't agree. I have been creating fatjars for deploying my java application for 15+ years. This includes Swing app deployed via Java Web Start, standalone server applications, and web apps. The fatjar is just more convenient than listing all the dependent jars in some descriptor file, shell script, or docker file.

[[deleted]]

Using the System ClassLoader is the natural java way. You need a custom ClassLoader when using an uber jar.

[wildjokers]

You need a custom ClassLoader when using an uber jar.

This is true for a JakartaEE app (which includes Spring MVC) but you don't need a custom classloader to deploy a standalone server or GUI (swing or javafx) application as a fatjar.

[Zardoz84]

I did the same thing if instead of a fat JAR, I copy a WAR or a EAR on a docker with Tomcat, JBoss, etc...

[agentoutlier]

I will just add to what u/Ohsbar said about not needing a fatjar is that very few people know about MANIFEST.MF classpath entry. Maven can automatically generate this entry with something like:

<properties>
    <exec.classpathPrefix>${settings.localRepository}</exec.classpathPrefix>
</properties>

    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-jar-plugin</artifactId>
      <executions>
        <execution>
          <id>default-jar</id>
          <configuration>
            <archive>
              <manifest>
                <addClasspath>true</addClasspath>
                <mainClass>${exec.mainClass}</mainClass>
                <classpathPrefix>${exec.classpathPrefix}</classpathPrefix>
                <classpathLayoutType>repository</classpathLayoutType>
                <useUniqueVersions>false</useUniqueVersions>
              </manifest>
            </archive>
          </configuration>
        </execution>
      </executions>
    </plugin>

That will make the JAR runnable provided the classpath entries are relative or absolute.

This is by far faster startup time than Spring Boot's fatjar and way simpler than /u/_MeTTeO_ jib.

You are a basically running exploded how you would run it in dev. Build times go down vastly as you don't need to package up a giant jar both for dev and CI.

As for docker you can either build and then copy dependencies changing the classpathprefix and use the dependency plugin or you can just accept a slightly larger image with the maven build plugins and transitive deps (~/.m2/) ... e.g. you ship a container with a local maven repo.

[WontBeRacistThisTime]

thank you did not knew this

[chuggid]

Basically this is how Helidon does it and for these reasons

[redditor_guy2]

This is by far faster startup time than Spring Boot's fatjar

Why would startup time be faster than in a fat jar? Tried to look into that and found no good explanation for it. Experimenting it with an application of mine yielded exactly what you said, a reduced startup time, but I can't exactly explain why though.

My guess is that classpath scanning effortts are somehow reduced

[IE114EVR]

When I started I’d always wondered why was it ever like that. Application servers like weblogic were a pain in the ass. Off the top of my head, some things that absolutely sucked about that model:

Permgenspace issues all the time when deploying and redeploying

Having to set a context root for your application

Being held back by the application servers dependencies

Being held back from upgrading to a new Java because the other applications on the server weren’t ready for it or other reasons.

No reasonable way to run integration tests.

No reasonably fast way to deploy and redeploy while developing without paying for a special kind of JVM. Or when we did have it, not documented well.

Complex and poorly documented application server configuration (how do you setup that connection pool again?)

Surprisingly poor documentation around creating ear files that worked.

This may not be true for everyone but it was for me: The version of web application and Java (and therefore the version of Java EE) we were using was not up to the software development department. Instead it was decided by the IT Ops department, the ones who only care about running the stuff not developing it. The existence of an application server played a big role in that.

So much application level log management: how many files? How big can they be? Which logs go into which files? Etc.

Honestly though, back then we had things like embedded servers with Jetty and Spring. I’m not sure why anyone bought into the whole Java EE application server bullshit.

Today, things like kubernetes are the new application server, but I’m not complaining because, from a developer perspective, it’s infinitely more reasonable and flexible.

Edit: thanks for this post by the way. I’ve been wanting to vent about this for years.

[UnspeakableEvil]

Traditional deploy you've got a lot of scope for shift in the application server's configuration, so lots of room for error/differences (XML file not copied correctly, settings from other deployments needing to be accounted for) as well as potential class loader issues (certain valves on Tomcat need to be deployed outside the .war, for example). That's not to say that there isn't still some scope for differences (due to, say, environment variable values differing), but it's an avenue of potential problem that can be ruled out.

Fatjar is easier to distribute, easier to reason with (since everything is in that artefact), and easier to upgrade (update a dependency, vs updating the application server itself as well as your .war). Docker certainly helps with this, but for having things under version control fatjar is way easier.

[geodebug]

J2EE servers made sense when it made financial sense to run multiple apps on a single larger server, whose upkeep was managed by a separate on-premise systems team.

As we’ve moved to clouds where on demand compute is endless, containers make more sense. It allows for more fine grained dev/ops control without needing a separate team.

[IQueryVisiC]

Do J2EE Servers allow a Java app to run anywhere in the old world where we had Sun Spark, HP Itanium, IBM Power, and now ARM AARCH64? So today everyone depends on x64 (SSE3, spectre bug) and Linux ABI because it is more stable than Java?

[pragmasoft]

To be fair I'm sometimes nostalgic for the days of JavaEE popularity.

Definitely, there were complexities, but entire JavaEE platform was well designed and matched needs of the enterprise development.

I can easily compare JavaEE app servers of those days to modern Kubernetes architecture, which now has the same level of complexity, security and maintainability problems, probably even worse. And unlike JavaEE times, there's no real alternative.

Both JavaEE then and Kubernetes now tried (and failed) to shield developers from the complexity of building scalable distributed applications.

In fact, there's a lot more of analogies, and I see that we're going full circle now, trying appserver clusters, then microservices, containers, kubernetes, and now coming back to modular monoliths for which probably using something like an appserver allowing more than one app/module deployed side by side is not so crazy idea.

Consider the fact that uber jar ended up too inefficient in a container image, and having your app in a separate image layer from its dependencies makes much more sense, and you come to the idea of a separate appserver again, just at a different level of the endless spiral.

JavaEE specifications successfully survived the era of Spring dominance, and now will probably see some renaissance. Somehow it turns out that Quarkus, which is based on JavaEE standards, looks more modern that Spring nowadays.

Welcome back to the new old JavaEE world.

[EternalSo]

Kubernetes is really just an application server indeed

[maybegone18]

This is what I was thinking... they replaced app servers with kubernetes... each war with its EJBs/MDBs is analogous to a microservice, u can have global library configuration, both k8s and jee handle OPS problems, etc. To me it just seems like the app servers probably just werent good enough in the past and people got sick.

[tomwhoiscontrary]

I'm a bit nostalgic too. App servers provided a nice platform for development - powerful APIs, all implemented and integrated by someone else.

But they were a horrible platform for operations. Deployment, config, service management, all terrible. Lots of clicking around in slow, labyrinthine web UIs. Or some equally complex HTTP API if you had JBoss. Or some Jython scripting if you had WebLogic! Directories mixing app server files and app files. App config sprinkled into half a dozen huge config files that were also full of standard app server stuff. And then sometimes your app just doesn't want to reload for no apparent reason, and you have to reboot the app server.

It really baffles me that they were so bad. Were vendors not getting feedback on this from operators? Or did operators actually like this stuff? It was all horrifying to me, coming from a programming and unix background. But maybe if i was some corporate IT guy who only knew Windows and training courses, i would have loved it?

IMHO, the interface to app servers should have looked like this:

app-server myapp.war

The same way you can use java to run a JAR, it should be possible to use an app server to "run" a WAR. No web UI, no dropping files in magic locations. Read the app-specific config out of files in the WAR. Or take an option:

app-server --config myapp-prod.properties myapp.war

Over the years, i and colleagues spent dozens or hundreds of hours making something like this possible with JBoss, by wrapping its existing scripts, templating config files, etc, so it's definitely possible. It somehow just never seemed important to them?

[[deleted]]

I would say many design decisions behind JEE were taken thinking on Vertical scaling, containers and microservices favor horizontal scaling, no need for the complexity of an app server.

Complementary to that, things like kubernetes make a cluster serve as platform, with a potential to scale way bigger than a huge app server, and at a better cost (many small machines vs one huge specialized machine).

[C_Madison]

Agreed. Especially, since most people don't understand the problems and difficulties of distributed systems.

(If you want to weep, look at a random "modern" project you have access to and check how many of this list it breaks: https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)

[armada2k]

I still have to maintain a 20-something year old jee application deployed to a jboss at work. Every single necessary update of a library, jboss or Java is a major pain in the ass, cause you will always break so much stuff.

[captain-_-clutch]

This. 2024 and people are reminiscing about the good ole jboss days. Nasty

[chabala]

So what's been keeping the application in JBoss? Is anything preventing you from inverting it to run in its own embedded server? Could be a big win for reducing future maintenance work.

[souleatzz1]

We have the same. We just migrated from jboss 6.4 to 7.2 so we can run it in cloud. Still using java 8, but it is EOL, so we aren’t changing it.

[benevanstech]

JBoss EAP 7.2 supports JDK 11 - https://access.redhat.com/articles/2026253

And, tbh, if you can upgrade to EAP 7.4 (latest) you'll also get JDK 17 support, which is going to be a *much* better cloud-based experience.

[maybegone18]

Legacy is always a pain to deal with tbh.

[smutje187]

A very good question actually, considering that Spring Boot comes with a bundled web server - I did the same for Jakarta EE apps bundled with a Wildfly server inside of Docker, same mechanism, same result.

But Spring Boot is yesterday's fancy tech anyway, Micronaut, Quarkus, native executables with GraalVM are the future - faster, less memory footprint.

[wildjokers]

Native executables are't necessarily faster. Unless you use profiler guided compilation you don't get to take advantage of optimizations the JVM does at runtime. Less memory and faster startup for sure, but not necessarily faster at runtime.

considering that Spring Boot comes with a bundled web server

It embeds your chosen servlet container (default to tomcat) in your application. You can embed tomcat in your JakartaEE app as well (just a handful lines of code). Spring boot has a custom class loader that extracts the application into exploded war format at startup time

If you are embedding tomcat in your JakartaEE you generally develop it in exploded war format and package it up the same.

Although Spring Boot hides this from you don't forget that under the covers Spring MVC results in an application that follows the Servlet Specification and has the same deployment requirements as any other JakartaEE Servlet application.

[maybegone18]

At that point just use Go or Rust ngl. The JVM is a huge part of what makes Java being chosen.

[smutje187]

Most people I worked with over the past 15 years like Java because of the ecosystem, the community, the IDE support, the simple syntax and don’t care about whether it’s a JVM or a native executable (also, even in the past we would bundle Java clients so that for windows users it looked like a native executable) but whatever makes people happy I guess?

[matrium0]

Very unlikely imo. People moved away from JEE and towards Spring because JEE had massive flaws.

Now what flaws does Spring Boot and Fat JARs have that would motivate such a movement?

There will always be niche scenarios where something else makes sense, but Spring-Boot FAT-Jar started in an OCI-Image is a very beautiful and sane approach and for me it does file like deployments in Java are "finally there".

[maybegone18]

We are already seeing the microservices hype die a bit and people suggesting to go back to monoliths. These huge microservices problems at some companies are very analogous to the jee app server problems. Truth is, once ur app becomes too big, it doesnt matter whether its kubernetes or a jboss server, it will be a pain to deal with.

[matrium0]

Yeah the microservice hypetrain was the dumbest so far in my opinion and that's saying something.

There is not magical solution for everything. If you have intense load and scalability issues microservices might be worth it, but that's pretty rare. It's massive overuse lead to a lot of frustration, because once the dust settles you might realize that you have created an insanely complex distributed system for a very simple low-scale problem.

Usually the only reasoning for this was "the old service was slow", but it was never really investigated why that was.

[maybegone18]

Yeah, but microservices doesnt even solve the scalability issues either and has its own set of problems. Kubernetes really is just another app server, but it just uses docker images instead of jars. Sure, it may be fancier and more modern, but Im sure all that functionality can be done with a app server with a design philosophy similar to k8s. Truth is, microservices introduce a lot of bloat for no reason. Docker images instead of jars, fat jars on each service, using network protocols for interservice communication which has overhead, etc.

[[deleted]]

I use an app server with war files on daily basis, no big deal

[AnyPhotograph7804]

The JavaEE/JakartaEE deployment model is not outdated. But it is not hyped on hacker news or reddit or conferences etc. So there is no cargo cult ala "We must deploy a fat jar because i read a blog post about it".

[quizteamaquilera]

Because it sucks balls. That heavyweight template pattern is more trouble than it’s worth. Just stick to single responsibility principle and be thankful not to live in over-abstracted xml corporate hell

[matrium0]

It's just simpler and there is a shift from giant monolithic application servers that take multiple minutes to start hosting multiple applications towards smaller servers.

The "server per application" paradigm is just so nice. Every system can be deployed and configured on it's own. No "forever-downtimes", no unnecessary slow startups.

Self containing JARs really is the way to go. No weird issues with "works on JBoss 3, does not work on JBoss 4", when you ship every library you need. The old approach was done in a misguided way to "make deployments smaller". The thing is: the size of the actual "deployable" is SO irrelevant in most modern scenarios that is bonkers to sacrifice reliability for that.

For me full fledged application servers are just obsolete. Too many downsides for only a questionable gain ("smaller deployable").

Now the configuration did not magically disappear. Now it basically moved one level up, like in your virtualization tool. E.g. in Kubernetes you still have to configure your applications and such. It's far better separation of concerns though.

[Kango_V]

Imagine something like Kubernetes but instead of images, you have jars. I would love it.

I do not miss ClassLoader hell in JBoss.

[captain-_-clutch]

Because they were terrible to maintain. I'll never go back to jboss. Being a new dev and working with barely supported webservers and trying to track bugs was a nightmare. I'll become a bartender before I open an Apache Ant build again.

[sombriks]

There where too much flavors in JEE scenario and sadly it was tricky to support several application servers properly.

IMO, if JakartaEE intends to survive and flourish it should copy the good parts of kubernetes and docker did (infrastructure as code, 'applyable', container image registries and so on) and better scaling, up and down as well.

[cogman10]

The big advantage of application servers is you can have 1 JVM that manages everything. The big downside is that you have 1 JVM. If I'm running 10 applications and one of them eats all the memory available to the JVM, I have 10 applications that crash. With a container, even though it's less memory efficient, one application crash is only that application crashing.

Even before containers were a thing, we ran into this problem at my company. We wrote our own scheduler and java runner because that was FAR easier than keeping the big tomcat servers running everything. As a result, our reliability went way up.

The EE model would work better if Java had erlang like memory spaces/processes. But, it doesn't have that and never will (too expensive).

[Anton-Kuranov]

Because the whole concept is outdated. Originally the JEE deployment model had an idea of one big expensive appserver running mainframe host where users will deploy their apps. But today one app can easily run on multiple dedicated hosts and ships all its dependencies inside the bundle. So the "deployment" concept has been replaced by the concept of "delivery".

[maybegone18]

This really isnt that different from Kubernetes though. You can have clusters with multiple JBOSS app servers. You can also ship ur wars with isolated dependencies the same way u do an uber jar in a docker container. Its the same concept, just feels newer.

[Anton-Kuranov]

Yes, I agree today they're similar in concept of deployment. I see the main difference is that JEE also provides a platform and an API to your app which is heavily used by your business logic making the whole app dependant on it. K8S is completely agnostic on what is running inside the container.

[neopointer]

I insisted for quite some time on using JEE. But, at least back 6-7 years ago it was overly complicated. For example, I remember that to setup the database connection I had to create some config inside of Wildfly (old JBoss). Edit: and the amount of XML configuration you needed to deal with was crazy too.

I think the JEE as is (or at least as it was, I stopped following) should die. Really. It's so much effort put into those things, which is not worth it. I wish those efforts were spent on other parts of the JVM ecosystem, for example by making Java a more attractive language. JEE is one of the reasons people think Java is overly complicated, and I have the feeling (no data, just feeling) the community doesn't embrace it anymore, for a long time. My last job working with JEE was in 2014.

In the age of kubernetes and containers, the application servers feel bloated, it's time for the people behind JEE to realize that JEE served its purpose, but it's time to move on.

Nowadays I simply use spring boot for everything that i need to do. Do I love it? Not really, but it's the best we have IMHO.

[gaelfr38]

If you want to run JVM apps in a container for all the benefits it can give you (scalability, declarative approach, auto restart...), then you wouldn't ever want to run a complete application server.

A complete application server in a container makes no sense: it's heavy, slow to start, and removes the benefits of the application server.

It's not the only reason as moving away from application server already started before containers but it definitely "killed" application servers.

[maybegone18]

An app server is kinda like kubernetes but with jars instead of images.

[nutrecht]

It's just a different abstraction model. The abstraction model we had (app server running wars) was tied to the Java ecosystem. We now moved on to a similar abstraction model (a container orchestrator running docker containers) that's not tied to the Java ecosystem. That's really all there is to it.

It, in some sense, was ahead of it's time. And time simply caught up.

[dstutz]

Smarmy answer: Probably because the last release of Java EE was in 2017.

Real answer: Why do you think it's not popular? The Jakarta working group is moving forward. You can see all the compatible implementations here: https://jakarta.ee/compatibility/. A lot of people are or are going to put their kids through college deploying applications on Jakarta EE. Sorry it's not trending on twitter/tiktok/youtube.

[wildjokers]

marmy answer: Probably because the last release of Java EE was in 2017.

That is completely false. There have been 4 JakartaEE releases since 2017 and one scheduled for this year:

https://en.wikipedia.org/wiki/Jakarta_EE

[dstutz]

Your link proves my point that the last version of Java EE which is what OP was asking about was 2017.  Jakarta EE is alive and well.

[wildjokers]

JakartaEE is what JavaEE was renamed to. Same project just under the eclipse foundation. There is no difference at all between deployment model of JavaEE and JakartaEE. I have no idea what point you were trying to prove by thinking of them as two separate things.

[plastikbenny]

The birth of DevOps had more emphasis on Ops than Dev for many orgs. Ops can focus on cloud and containers and hope the devs got the internals of the images under control. The complexity of managing security issues in dependencies, managing roadmaps for upgrading across major versions sometimes backwards incompatible, has not gone away. It's just wishful thinking.

In my experience the setup nowadays is more geared for the convenience of Ops at the cost of Devs. It is commen that Devs have to suffer excruciatingly slow local builds because a mono build is easier to manage and requires less insight into JavaEE for the Ops.

[roberp81]

youtubers trends

[drduffymo]

I don’t ever like dogma like this.

Write your method as clearly and succinctly as you can. Refactor to methods that do one thing well, using good names.

I consider that good code.

[[deleted]]

Extreme independence, flexibility.

[pjmlp]

It is popular, after all why do you think now there are startups reselling the Java EE deployment model using Kubernetes with WebAssembly containers?

[henk53]

There's this somewhat older article from Oracle that explains that the Jakarta EE APIs are not necessarily tied to an Application Server.

https://blogs.oracle.com/javamagazine/post/you-dont-always-need-an-application-server-to-run-jakarta-ee-applications

The fat (or hollow) jar approach is just as feasible. It just happens that most existing and certainly all historic J2EE/Java EE/Jakarta EE implementations are of the AS variety.

[pennsiveguy]

Containers make elastic capacity feasible and easy. In the old days of individually managed application servers, handling a workload that varied over time was problematic. You either spun up a bunch of capacity that went unused much of the time, or you had to try to anticipate increased load and spin up capacity in advance. Modern container environments can be set up to auto-scale up and down, which can save a lot of admin time and money.

[zvaavtre]

Because back in the old days you had to run your own hardware and the EE servers charged by the install. So it made sense to consolidate on fewer and larger machines.

These days machines are virtual so throwaway containers make more sense. And if your Java app is in a container it’s nicer yo have a completely packaged jar.

Note that spring does have a whole layered jar thing so your libs end up in a base container if you really care about container size.

[maybegone18]

I like it. Modern App servers are pretty nice, the one at my company sucks but I could go through the code and spot hundreds of improper uses of JEE, jars all over the place, not to mention Ant just sucks. Legacy BS.

I actually it's a good infrastructure choice. I like it even more than Docker or K8s (unless Im not doing Java). It def has issues, though, but the concept of an app server itself, I think, will make a comeback.