In defense of J2EE’s complexity
J2EE bashing seems to be the flavour these days. While I do agree that J2EE does seem tedious at times, especially when you compare it with the likes of Ruby on Rails, I still realize (and appreciate) why and how J2EE got to be the way it is.
The Build Process
It all started with ANT. ANT is was a little tool to manage Java builds. Before ANT, building a Java app was no small task and involved writing convoluted scripts. ANT enlightened us with it’s build.xml. This was amongst my first introductions to XML configuration.
MVC Architecture
Next came Struts. Before Struts, we used to write massive amounts of code to do simple form validations. I cringe looking at really old code that we had written with complicated JSPs and validation logic spread across JSPs, classes and even JavaScript files. Struts introduced us to the world of MVC. Before Struts, we only heard people say they use MVC, but digging a little deeper revealed that people had their own notions of MVC. With Struts came Tiles which made managing templates for large, demanding projects a breeze. Struts was literally a knight in shining armour, rescuing developers from the mundane tasks of web development.
Database Nirvana
There still was the issue of writing good, maintainable code for the database access layer. Making this portable across databases (even with JDBC) was a huge nightmare. We often ended up with multiple implementations for each database vendor tied to the application by an interface. Forget portability, as an application grew in it’s level of complexity, writing code to support one database itself was hard to handle. I tried JDO but that seemed to suck like all technologies that are made by corporate consensus. To the rescue came Hibernate. With hibernate, we just had to write code for one database layer - hibernate and it took care of the rest. It’s relative simplicity was un-imaginable at the time. Database portability issues were a thing of the past.
XML Configuration Nirvana
But using hibernate had it’s own problems - XML configurations! As our application grew larger managing XML config files really started to hurt. To the rescue came XDoclet. With a few tags in the comments, the XML files were now “automagically” generated for us by pluging-in XDoclet with ANT.
Hibernate Nirvana
There was still one more problem with hibernate - managing transactions and hibernate’s database conversational sessions could easily get out of hand as the project grew. In comes the “Spring Framework” bringing along with it “Declarative Transaction Management”. Hibernate was fun again.
Spring is truly the glue to a lot of important services that a typical J2EE application would need. So since we were anyways using Spring cos of hibernate, why not use other services that it provided. Thus came in DWR for AJAX, Quartz for scheduling, AOP (which Spring makes really easy to do), etc.
Sum of all complexity greater than the sum of parts
J2EE was simple again! Wait… but that’s not true… I must be loosing my mind! How can all the stuff mentioned above; ANT build files, Struts, Tiles, Hibernate, Spring, AOP, XDoclet… be simple? Well it’s not if you wake up to it TODAY and look at it. However, looking back over the years, J2EE has evolved, introducing new stuff each time solving an even more complex problem. Stuff that now seems complex when taken in as a whole.
I often have a hard time training a new recruit, fresh out of college, on J2EE and related libraries. The poor guy gets overwhelmed with all of it. Besides, since he hasn’t done it the “hard” way, all these libraries seem to add to the complexity rather than simplify anything.
But then I also come across some guys, again fresh out of college, who “get it” easily. I don’t need to spend hours explaining stuff to them. It just makes sense - one thing at a time.
The real Evil
The new recruits some times ask me about this really cool enterprise thingy called ‘EJB’ that their friends are working on at other organizations. And all I can tell them is that EJB was a HUGE mistake, something which I wish could be un-invented. The EJB spec was created so that IBM, BEA, Oracle, etc could make money. (I’ve not added SUN to the list cos it looks like they’re the only guys who couldn’t make money off J2EE though I’m sure they tried). EJB deserves to be bashed!
…But not any simpler…
So coming back to complexity, certain things are inherently complicated. Multi-tiered applications are certainly among them. Technology alone cannot reduce complexity, though I’m sure J2EE can do better at it. If you reduce complexity to a level that BOZOs start to contribute, you end up with even more serious problems. Any one whose had to maintain a VB application would vouch for me here. Software engineering needs to have a certain barrier to entry to keep BOZOs out.
Consider this, if tomorrow Boeing made a 747 Passenger Jet easy to fly, would you trust a bus driver to fly you around?
(24 votes, average: 3.29 out of 5)
Loading ...
November 7th, 2006 at 11:11 pm
Could you expand on why you think EJB’s deserve to be bashed?
November 7th, 2006 at 11:13 pm
thank you for the historical overview. This put some of the many J2EE components into perspective. I’ve attempted to learn J2EE as an outsider, but quickly became frustrated with the many ways to do things and the constant “well you can do it this way, but really it should be done this way.”
Do you know of any books that attempt to teach J2EE with the current state of technology in mind? kind of like a get up to speed book.
November 7th, 2006 at 11:16 pm
Jeff,
There isn’t any particular book that I’m aware of. However, I’m in the process of making up some notes on how I think it’s right to go about J2EE. Think I’ll post it up here.
November 7th, 2006 at 11:53 pm
You need all this XML because Java isn’t flexible enough so you can’t do it in Java.
November 8th, 2006 at 12:33 am
xml is needed for easy configuration, not because its not flexible. You could do everything with Java, it will just take a lot more code.
The reason for complexity is because of the choices, and freedom JEE provide. You can be a complete incompetent programmer/developer and get by doing .NET, cause MS will tell you exactly how things are to be done, and what tools to use. Where as in the Java enterprise world,, you do need to know your ish to be an architect. Deciding what technologies to use to tackle n problems differentiates the good from the best.
November 8th, 2006 at 12:54 am
The question is are the problems each layer solved created by the job our by the underlying layers? Instead of fixing Ant, they add XDoclet? Instead of fixing Hibernate, they threw Spring on top? Perhaps using a complex multi-tier architecture is the real problem?
November 8th, 2006 at 2:18 am
Jules wins the retarded-comment-of-the-day award.
All the XML configuration applied to Java projects end up being parsed, evaluated and applied *BY* Java classes *TO* Java classes.
So it isn’t that XML is there because “Java isn’t flexible enough”, it’s because one would rather not pour through a bunch of source code looking for JDBC connection strings and hope you get them all before kicking off your build process.
As for beza1e1’s comment, I think if you consider it for a little bit, you’ll find that there are very few classifications of problems where you’d want your presentation, biz logic and persistence in a single layer. Like Blogic said, “certain things are inherently complicated. Multi-tiered applications are certainly among them.”
November 8th, 2006 at 3:29 am
I don’t think that beza1e1 was saying to take the M out of MVC, or to flatten out the tiers. Rather I think the comment was meant to say that rather than refactoring the existing tool to scale an additional tool, and now sub-layer, was put on top of it instead.
Frankly, I believe that all of this CAN be done without overdoing the complexity like J2EE has. Look at RoR, mentioned in the beginning of the article. It is firmly MVC. There’s a solid model abstraction layer in ActiveRecord, and guess what? It’s really slick and easy to use. There’s a very nice — componentized — view layer. It’s really slick and easy to use. And the controllers — well they’re as natural as writing a form-mail CGI for the 100th time in your favorite language.
Java is in itself overly complex. After how many years did it finally get a split function for strings? Java Developers have always been more content instantiating a StringTokenizer, then getting an iterator from that, then looping, then blah blah blah. Gimme a break. Java people think it through to such depth that they never realize they stopped properly thinking it through soooo long ago. That’s what happens when you use a language created just to woo C++ programmers.
J2EE solves no problems, it simply creates new ones.
November 8th, 2006 at 3:34 am
… thanks for the good read
)
It’s the complexity of the entire ’system’ that makes it a long journey from your System.out.println(”Hello from Cessna 150″); to ‘enterprisey’ 747-Java. Learning, system’s complexity and flexibility all add up to one of those ‘the more I learn the further I can see’ adventures. If your starting point is in a fast food store or driving a bus - so be it - CRJ’s and 747’s will be there for you if you’re willing to put in the sweat, blood and tears. Complaining will do you no good.
November 8th, 2006 at 6:40 am
Chunks of Butter,
You’re forgetting the audience. Ruby is great if you’re a single developer but try putting a team of 10 or 20 developers (or more) on a Ruby project and it would be a disaster. The weakly/dynamically typed languages are simply not appropriate for teams of developers.
November 8th, 2006 at 7:45 am
Dan: As development teams grow, few bugs are prevented by type-checking. You tend to get a lot more functional and intent bugs, especially for data-driven apps. A compiler just isn’t that much help, compared to asserts and unit tests.
Besides, with dynamically typed languages, you’ll only need 5 developers, not 20.
November 8th, 2006 at 11:25 am
Srini,
Well put
. Although, I personally think that when a project team size is 20, just 5 are actually doing the work. The rest are to beef up the billing since most IT service companies charge by the man-hour! A knowledgeable team doesn’t require 20 guys even when using J2EE.
November 8th, 2006 at 11:37 am
[…] In defense of J2EE’s complexity J2EE bashing seems to be the flavour these days. While I do agree that J2EE does seem tedious at times, especially when you compare it with the likes of Ruby on Rails, I still realize (and appreciate) why and how J2EE got to be the way it is. […]
November 8th, 2006 at 6:33 pm
“Software engineering needs to have a certain barrier to entry to keep BOZOs out.”
classic! But this is where you lost me:
“A knowledgeable team doesn’t require 20 guys even when using J2EE. ”
Not all software can be written by 5 man teams. There are big projects too, lots of them.
November 9th, 2006 at 1:31 pm
It’s been 3 weeks now that I go everyday to work and don’t dare to write a single line of code.
This is my fifth J2EE porject in six years and the only thing I can say is that I didn’t get anything back in exchange of the effort I put to learn J2EE and all of its corner sides.
Am I a better programmer because I know J2EE, am I a better problem solver?
Hell, no.
I think I’ve learned a lot more in the last 2 years playing with CommonLisp, Scheme, Smalltalk, Haskell, Ruby, Python, Erlang, Ocaml, Prolog and even Perl than I will do if I spend all my life using Java/J2EE.
How can one still bear using Struts again if (s)he, once, happens to use RoR or Seaside or Django? For classic applications with databases behind(and that’s what I do most of the time), it isn’t even faster!!
anyone watched this screenacst http://oodt.jpl.nasa.gov/better-web-app.mov ?
Do I really have to re(compile|deploy) every single time I change the code just to make sure that I won’t catch a ClassCastException? As I said it’s been six years now, and java never stopped taking me for a “BOZO”.
Ant is for masochists, it became a full programming language by itself with the most annoying syntax ever(that is xml). Let it grow and we will soon have the lisp-macros constructs, xml closures and such things as “Any sufficiently complicated platform contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.”
I wonder why we don’t use CL instead?
Now, I don’t want to complain further about java or J2EE. I have to accept it and live with it.
November 9th, 2006 at 3:35 pm
Hi dormant and all,
Yes J2EE can be a pain, but it does not have to.
For dormant and the likes, here’s less java for more applications:
http://developer.berlios.de/projects/less4j/
Because I won’t wait for RubyOnJ2EE, I’m tired of HttpServletSession woes, I can’t take another HellWorld tutorial in 26 steps, I want JSON validation now and performances do matter.
January 4th, 2007 at 12:41 pm
I guess for me J2EE means EJB’s rather than Hibernate and Struts etc.
I was expecting you to be defending EJB but that does not seem to be
the case
Anyway, I thought I’d add a thought which is that we (as Java developers)
need to keep in mind “As Simple as possible but no simpler”.
Q: Do you really think Hibernate/JPA is as simple as it can be?
Me: I don’t think so, in that I think we can remove the overhead and complexity of
session management for starters (see http://www.avaje.org)
Q: Do you really think Struts/Tiles is the most productive web framework?
Me: I’m expecting groovy based web frameworks to be a significant improvement.
We have a bit to do to catch up in this regard.
June 12th, 2007 at 2:40 am
In defense of J2EE’s complexity…
[…]J2EE bashing seems to be the flavour these days. While I do agree that J2EE does seem tedious at times, especially when you compare it with the likes of Ruby on Rails, I still realize (and appreciate) why and how J2EE got to be the way it is.[…]…
September 5th, 2007 at 1:16 am
[…] http://blogic.www2.aurigalogic.com/nikhil/2006/11/07/in-defense-of-j2ees-complexity/ Posted by corneliusj Filed in RoR, Ruby, PHP, Technology […]
November 4th, 2007 at 1:28 am
[…] Why J2EE is complex I read in O’Reillynet a comment on AurigaLogic’s Blogic. […]