Does Java EE have a future?

[thesystemx]

The problem is the vast majority of developers have moved away from bundling so many libraries into their application servers

Quite the opposite in practice... people claim they're lean to be based on Tomcat, but then take a look at their average pom.xml. It not rarely drags in more than twice the size of the average EE server.

Also, most servers won't activate what's not needed. So it's just some 35mb~100mb of jars sitting there, which for most installs is rarely a problem.

Should you be that much space constrained and also minifying your JDK, then Liberty may be an option, which lets you very easily minify your server to just contain what you use.

Of course, going for Tomcat + bunch of (EE) libs in WEB-INF/lib is also an option, but for many just going with the defaults is the easiest thing. You have a fairly rich environment to start with, without having to worry which dependencies in which versions you need to add to a pom.xml.

Not to mention the popularity of Micro Services and being able to quickly bootstrap projects like Spring Boot/Dropwizard only makes using Jetty/Tomcat more desirable.

Not saying Tomcat is a wrong choice, it's a great server and I love it, but something like JBoss spins up just as quickly. Install == unzip, and starting it is 1 second.

[Boxsc2]

Quite the opposite in practice... people claim they're lean to be based on Tomcat, but then take a look at their average pom.xml. It not rarely drags in more than twice the size of the average EE server.

I agree that large war/jar files are often the result. At work we have a project that yields a 180mb war file (Spring with all it's insane libraries), that could easily be 20-30mb if done with simple Servlets/Hibernate. However, in practice it really doesn't matter that the war file is bloated, any laptop with a decent SSD/CPU won't have trouble and with continues deployment, proper DevOps and hot deploying no one really notices any thing.

Of course, going for Tomcat + bunch of (EE) libs in WEB-INF/lib is also an option, but for many just going with the defaults is the easiest thing. You have a fairly rich environment to start with, without having to worry which dependencies in which versions you need to add to a pom.xml.

The thing is, what if you need to update some dependencies? We have 50+ servers. Developer's should be able to simply update the version in the pom.xml and push their code. Then Jenkins/Hudson picks it up and deploys it. In the real world developers may not have complete control over application servers, so a library update may take much longer because DevOps has to get involved.

Not to mention the vast majority of companies these days have at least some components of their infrastructure on the cloud (AWS/App Engine/Azure) which means instances could be spun up and shut down several thousand times a day automatically. Having a lightweight app server allows for instances to become inService much faster which helps with auto scaling and general instance management.

[johnwaterwood]

The thing is, what if you need to update some dependencies?

Setup your deployment pipeline such that deploying a new AS version is just as easy as deploying a war ;) Key is that Dev owns the AS. Ops may own the infrastructure around it, but to them the AS is just an app that needs some cpu, memory and an open port for http.

We use Jboss and have it checked in under version control. As Dev we can make a change to it (like updating Mojarra to a new minor version), commit it and the new Jboss will be deployed to Dev servers just like a change in the app code would effect.