HTML5 Zone is brought to you in partnership with:

Brian has 10+ years of experience as a technology leader and architect in a wide variety of settings from early startups to Fortune 500 companies. With experience delivering SaaS solutions in business intelligence, artificial intelligence and VoIP, his current focus is big data and analytics. Brian leads the Virgil project on Apache Extras, which is a services layer built on Cassandra that provides REST, Map/Reduce, Search and Distributed Processing capabilities. Brian is a DZone MVB and is not an employee of DZone and has posted 61 posts at DZone. You can read more from them at their website. View Full User Profile

J2EE is Dead: Long-live Javascript Backed by JSON Services

10.29.2012
| 39746 views |
  • submit to reddit
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 event-driven systems. 

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 stack: pure javascript backed by light-weight JSON services.

This is where we've landed.  We use straight-up javascript for our 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.
Published at DZone with permission of Brian O' Neill, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jason Cone replied on Mon, 2012/10/29 - 7:04am

Timely article, for me.  My front-end development has moved to JavaScript, too.  The back-end of my latest project is a servlet that provides JSON to the client.  (However, the servlet is still using JEE container-managed security and talking to some pre-existing EJBs.)

 For future server-side projects where I don't have a pre-existing JEE structure in place I'm taking a hard look at node.js.  I may end up with straight-up JavaScript on both client and server.  Not sure, yet.

Robert Saulnier replied on Mon, 2012/10/29 - 7:26am

In most webapps, JEE might be considered overkill, but when dealing with financial transactions, JEE is alive and well.

Mike Dzone replied on Mon, 2012/10/29 - 8:55am in response to: Robert Saulnier

You stated "the canonical enterprise stack: Spring and Hibernate on Tomcat. " I know many organizations do this and do you want to know why? It's because they are trying to turn Tomcat into an EE Server!!  Why do that when when great EE Servers already exist. Why re-invent the wheel?  Do yourself a favor, don't try to hack Tomcat into something it's not.  Use a real EE Server like GlassFish.  You'll be much happier.

Jonathan Fisher replied on Mon, 2012/10/29 - 12:27pm in response to: Mike Dzone

@Mike Dzone Or just use TomEE... which is indeed a 'real' EE server: http://openejb.apache.org/

 

Honestly though in regards to the article, Javascript sucks. It's a pain in the ass to manage large Javascript codebases and the lack of mature tooling makes matters worse. There are huge runtime advantages to the JSON/JS architecture; too bad client-side Java spent 10 years not delivering on any of them.

Mark Unknown replied on Mon, 2012/10/29 - 12:51pm in response to: Jonathan Fisher

I have to agree with Jonathon about JS. I know that in some cases it is a necessary evil. But having tried to pick a JS client library and having had to deal with other peoples "scripting" code (and non-scripting for that matter), i just can help wishing for a [much] better option.

Mark Unknown replied on Mon, 2012/10/29 - 12:56pm

I am not sure why using JS and JSON has anything to do with J2EE ... i mean Java EE ... and thus it being dead.

Also, using an ESB does not remove the need for something like JMS in your applications.  Committing outside the container, in many cases, defeats the purpose.

 

Diego Visentin replied on Mon, 2012/10/29 - 2:46pm

IMHO history repeats itself. VB fat clients with stored procedures on db is not so different to HTML5/JS apps that talk with REST-style data backends.  But maybe I'm only too old  ;-)

Mark Unknown replied on Mon, 2012/10/29 - 3:17pm in response to: Diego Visentin

But they are different in that the client is not directly accessing a database. That and any necessary abstractions happen between the ui client and that database. That being said, i was doing it (a layer between the client and db) with VB in the late 90s. :) 

André Pankraz replied on Mon, 2012/10/29 - 3:30pm

Hi,

less blogs, conferences and startups - start writing real business web apps and you will see that JEE is not dead at all. It's really just the context you are used too - I could claim C/C++ are dead, but they arn't, I just don't work in this field.

Best regards,
André

 

Ray Ploski replied on Mon, 2012/10/29 - 8:08pm

Java EE is far from dead although it's not close to being a complete solution for many situations.  Even the author touts parts of the specification (directly or indirectly) including: JMS, JAX-RS, JPA and the Servlet specification.  Trying to create a Java-based enterprise application without the contributions of the Java EE specification would be like trying to write this article without vowels.  I remember writing apps upon BroadVision that required both client and server-side JavaScript.  We did backflips once BV offered support for JavaEE containers. 

Without a doubt, JavaScript and Rails doubt have their place in any developer's toolbox but so do the contributions of all of those who gave us an easier way to implement many of the non-functional requirements needed in systems. 

Jason Cone replied on Mon, 2012/10/29 - 10:30pm in response to: Jonathan Fisher

I used to feel that way about JavaScript, too, and thought Java far superior.  However, when I took another look at JavaScript not too long ago, and brought along my familiarity with Scala and Clojure, I saw things in JavaScript that I had missed the first time around (when I was looking at it more like a poor-man's "toy Java").  Thought I might be crazy.  Then I read Crockford's book and decided that I wasn't crazy, after all.  

I wouldn't say JEE is dead (not by a long shot); and for most enterprise apps using Java on the server I'd rather have a full-blown JEE container, rather than something grafted and patched together around Tomcat.  

But I think JS rules the client, and JSON is the big dog for JS<->Server-Side communication.  And with JSON's increasing importance on the server, faster JS engines and event-driven architectures that scale on multicore CPUs, etc. -- well, JS on the server shouldn't be ignored, either.  I'm not claiming it's on par with Java for enterprise server development, just saying that having JS on both ends, speaking JSON, and using Javascript's event-driven architecture, has some definite benefits. 

I agree that the JS tooling I've tried hasn't been as impressive as what is available for Java.  Right now I'm using emacs with a handful of customizations for syntax/indention/JSLint/snippets/etc, and that seems to work pretty well (but I'm very comfortable with emacs, in any case).  WebStorm is supposed to be pretty good, but I haven't tried it.  

Anyone coding JavaScript would probably benefit from JSLint, though.  Nice tool.

 

 

 

Adrian Meredith replied on Wed, 2012/10/31 - 4:47am

J2EE has been dead for years, its now called JEE.  You would know this if you actually used it.  As quite a few people have noted, if you're building a real application JEE is pretty unbeatable.  Our application, like yours uses a javascript client (ember/handlebars) BACKED by a JEE6 backend. We make use of these technologies and couldn't be happier, with this architecture we get ms request/response/render times

jax-rs (rest)
ejb
jms
CDI
bean validation
hibernate
apache lucene
  


Greg Brown replied on Wed, 2012/10/31 - 11:13am

You might want to check out Java EE 6. It is pretty much the lightweight services environment you describe. A lot of the heavyweight stuff that gave J2EE a bad name is gone now.

 

Shane Johnson replied on Wed, 2012/10/31 - 12:50pm in response to: Mark Unknown

I couldn't agree more. The title lets me know that this article has little to no technical credibility.

This is similar to the last article stating that Java EE was dead. It too mentioned AJAX & JSON.

To the author,

Can you stop referring to it as J2EE? Yes, J2EE is naught but a distant memory.

Here's the thing, that same simple JAX-RS class that you mention. Well, that is the same one deployed in a Java EE application. It seems all you really want to do is use Java EE APIs (JPA / JAX-RS) without a Java EE application server. Let's face it, your application architecture is not that different from Java EE. I can package a single JAX-RS annoated class with no other dependencies or package imports and deploy it. How is that different than what you are doing other than it is not deployed as a WAR and it is not deployed to a Java EE application server?

Adam Gent replied on Wed, 2012/10/31 - 1:59pm

One could even argue that EIP systems like Camel, and ServiceMix may die also as it is rather complicated and could be replace by simpler event driven message systems directly (Akka, RabbitMQ, and or Hadoop etc). 

EIP today reminds me of SOAP and J2EE a couple of years ago. The abstract idea of EIP is a good idea just  like "Web Services" was a good idea but the SOAP sucked and REST won.

For the most part EIP is just event driven message system with some routing. Not to mention anytime you put "Enterprise" in the name and your just asking to be ignored (particularly in the startup arena).

Lately I have had great success just using RabbitMQ and a modified Guava EventBus. Other times I just use Akka.

One thing is sure Java is still the performance king. The success of Node.js will probably only help Java (compared to Python and Ruby) and place it where its more suitable (backend middleware and number crunching). That is I foresee many people doing something like:  "Node.js + Java + Event Bus".


Andy Moncsek replied on Wed, 2012/10/31 - 2:21pm in response to: Diego Visentin

@Diego,  "VB fat clients with stored procedures on db" you are absolutely right... nice comparison ;-)

Mark Unknown replied on Wed, 2012/10/31 - 11:10pm

@Andy, they are similar, but VB Clients typically had the data access embedded in them and held open db connections. The good news is that we are going away from the horrible web req/response/repaint paradigm.

Mark Unknown replied on Wed, 2012/10/31 - 11:22pm

@Adam, If Java EE were dying you could argue that EIP was or will too. But since Java EE is not, I doubt EIP will. EIP is more than just some routing. They provide other things such as message and transportation transformations.  If you just use RabbitMQ and Event Bus then you will be writing all the other stuff yourself.  If you have a homogeneous system then you probably can get away with just Messaging and Event Bus. But most companies (aka enterprises) are not.

http://camel.apache.org/enterprise-integration-patterns.html

http://camel.apache.org/components.html


As for Node.js and Java, a better option would be http://vertx.io/ and thus avoid JS on the server.

Jammer Man replied on Thu, 2012/11/01 - 3:07pm

I love it "J2EE is dead."  Just priceless.   Enjoy your little slice of programming heaven on some backroad of the information technology highway whilst the rest of the world continues to build fault-tolerant, performant, transactional and scalable systems using JEE.

Some "technology leader" you are.

Tomasz Bozek replied on Sat, 2012/11/03 - 2:25pm

 I have enough of this :). Tell me why Software Designers try to improve others thaht the technology which they use is the best. Like Spring fans always try to say that it's the best framework - well i don't agree but nobody is perfect :). Of course they remeber the old J2EE and they compare it to the new Spring stuff which is for me really funny.

From my perspective the most important thing is that when i have a group of developers i need to have a clear enviroment , framworks, design patterns etc. JEE 6 currenlty is the best choice.

You don;t need to use a bunch of xml's to definie something :). Just Create , deploy and have fun.

Currently for me the best solution for web applications are

primefaces + jsf 2.0 + ejb 3.1 + hiebrnate + glassfish.


1. I don't have to worry about Java Script which is for me a pain in the ass  - especialy when poor developer takes control over it and tries to do something with it ! 

2. JPA is good and stable solution for me i can use hibernate , toplink  and many other venodrs if i want + any SQL db 

3. EJB's are good bussines layer 

4. Primefaces makes my faclets web pages clean without any java script and with a lot of components based on jquery

Thats all thank you :)


Ahmed Samir replied on Mon, 2012/11/19 - 5:02am

@Tomasz Bozek

+1 on 'primefaces + jsf 2.0 + ejb 3.1 + hiebrnate + glassfish'

for me, this stack is all what i need, prime faces with jsf 2.0 offers me clear perfect view without the need to deal with -IMHO- undisciplined js, perfect business layer with ejb, and you know what? i don't care about whether to use hibernate or eclipse link on top of what ever database.

js and json are powerful, but Java EE has a wider context; the context of security, transaction and messaging, NO, Java EE is far from being dead.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.