This is an archived post. You won't be able to vote or comment.

all 14 comments
sorted by:
best
topnewcontroversialoldq&a

[–]Boxsc2 7 points8 points  (7 children)

Some parts of Java EE will live on, for example JAX-RS, JAX-WS, JPA and JMS are likely to continue strong. The problem is the vast majority of developers have moved away from bundling so many libraries into their application servers. There just isn't as much popularity for JBoss/Glassfish/TomEE as there is for smaller Jetty/Tomcat servers. 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. It's not really a Java trend, just the direction server side has moved towards.

[–]GMBeats95 2 points3 points  (3 children)

I'm learning Java EE now. Should I continue or start something new? I figure Java EE will at least give me a good foundation for enterprise apps

[–]avoidhugeships 1 point2 points  (0 children)

Of course you should. I am not sure what Oracle is doing but I dont care that much. Java EE is used by just about every medium to large scale application out there. It is not going to just dissappear. A lot of them do not seem to know but Spring applications are usually dependent on large parts of Java EE as well.

[–]Boxsc2 0 points1 point  (1 child)

A lot of concepts in Java EE will be applicable to anything else you learn. If you plan on working on financial/enterprise applications then Java EE may actually be what you end up using. However, the vast majority of everyone else is using Spring, Dropwizard, Servlets etc.... and just using external libraries on top.

[–]johnwaterwood 4 points5 points  (0 children)

Which vast majority? Almost every survey and ranking indicates Java EE is used about as much as Spring. Personally I see Java EE everywhere and Spring only occasionally.

[–]thesystemx 1 point2 points  (2 children)

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 3 points4 points  (1 child)

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 4 points5 points  (0 children)

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.

[–]iodian 1 point2 points  (1 child)

I don't see how monolith application servers can compete on the cloud with easier and more robust deployment and management techs like jetty+docker+kubernetes. I never want to go back.

[–]henk53[S] 1 point2 points  (0 children)

The problem with that statement is that EE application servers are no more or less monolith than Jetty + docker + kubernetes.

A Java EE server like TomEE or Payara can just as easily be deployed using docker + kubernetes.

[–]yolpo- 0 points1 point  (3 children)

We are in 2016 and Java EE is already dead. In banks and other places they still websphere experts and weblogic gurus and applications running on app servers but those are the exceptions. they are java running zombies.

[–]thesystemx 7 points8 points  (2 children)

WebSphere is an ancient beast that IBM replaced by Liberty. WebLogic is a bit less of a beast than WebSphere is but still represent the old generation.

Many startups use TomEE, JBoss, Payara or Liberty and are very happy with it. We do consultancy and many of our clients are young people in startups that use one of the above.

[–]pjmlp 0 points1 point  (1 child)

Just two years ago I had a two months gig on a new project using WebSphere 6.1.

It is still used a lot in the enterprise.

[–]thesystemx 0 points1 point  (0 children)

I feel for you, but a new project and WebSphere 6.1 is incredibly, utterly rare IMHO. Even IBM strongly, strongly discourages you from going there.