Hello, my name is Brian O'Neill, and I've been J2EE free for almost 8 years now.
A long time ago in a blog post far away, I asked the question "Is J2EE dead?"
Almost five years later, I'm here to say that, "Yes, J2EE is dead".
In fact, I'd say that it is now generations removed from the emerging
technologies, and an ancestor to current enterprise best practices.
Originally, I thought that the MVC and HTTP/CRUD portions of J2EE would
be replaced by rapid development frameworks like Rails. The back-end
non-http portions of the system (e.g. JMS) would move outside the
container into Enterprise-Service Bus's (ESBs) and other non-J2EE based
In large part, I think we've seen this trend. Increasingly, enterprises
are adopting Fuse, Camel and Mule to form an event-driven backbone for
the enterprise and although I don't believe we've seen as wide an
adoption of Rails in the enterprise, I think we've seen a strong
movement towards light-weight non-J2EE containers for web application
deployment. In fact, I didn't realize just how much the deployment
landscape has changed, until I saw this survey, which showed that half the enterprise servers are running Tomcat followed by Jetty at 16%.
We're perhaps on the extreme end, since we've abandoned war files entirely
, swapping them out for the Dropwizard framework with an embedded Jetty Server. (and we're loving it)
Now, I think most enterprises are rolling out successful deployments
using what I believe has become the canonical enterprise stack: Spring
and Hibernate on Tomcat. The more daring are striving for even higher
realms of productivity and are breaking new ground with an even lighter
front-end. Although I'm a huge fan of jquery, we've gone with ExtJS.
With it, we deliver a single-page webapp that can be deployed to
anything capable of serving up raw HTML. (e.g. apache web server) No
more servlets, nor more containers of any kind. This enables our
front-end developers to be *incredibly* productive. They don't need to
run a server of any kind. We stub out the JSON services with flat
files, and they can plow ahead, cranking out kick-ass look and feel and
slick UX. To be honest, they probably haven't heard the acronym J2EE.
(and probably never will)
Meanwhile, back at the (server) farm, our java-heads can crank out
light-weight services, which replace the stub JSON files with real
services that interact with the back-end systems. To keep them
productive, again we cut the fat, we stay in J2SE and roll simple JAX-RS
based services that we *could* deploy to Tomcat, but we choose to
deploy as individual processes using DropWizard. They are simple java
classes that anyone can pick up and start coding after only reading the
first couple chapters of Java in 21 days
This not to say that we don't leverage elements of the J2EE stack (e.g.
JMS and Servlet Filters for security, etc.), but even those we are
beginning to replace with web-scale equivalents (e.g. Kafka). I can see
the day coming where J2EE will be naught but a distant memory.
"Alas poor J2EE, I knew him (well)."
We'll miss you.