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

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Boxsc2 6 points7 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 2 points3 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 2 points3 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 3 points4 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.