Frankly, the rise of Spring and Hibernate (and Toplink, and now JPA as part of the EJB3 spec) was really a grass-roots developer community response to extremely serious issues of sorely lacking functionality (AOP, DI etc) and serious performance limitations (EJB2) within the J2EE architectural stack. Spring and Hibernate were born from the painful experience of software developers and architects who built real systems and found that the (so-called) “J2EE Blueprints” just didn’t cut the mustard in a real-world scenario (especially a demanding transaction processing one).

In fact, as a former CORBA developer yourself (as you state in your post), I would have thought you would have been well positioned to observe what is (in my view) the *fundamental* limitation of the early J2EE design model: its sufferance (to a large, and now thankfully a decreasing extent) from *design by committee* - the very same affliction that basically killed CORBA. The whole open-source “build first, standardise later” approach adopted by Spring / Hibernate, etc is the very antithesis of the former approach. Distributed innovation and “best technology wins” has finally started to trump “most powerful / influential vendor” and the results are (blissfully!) finally beginning to show.

So I don’t think Dan was intentionally “J2EE bashing” in his post - but he was questioning the depth of knowledge held by the very many people now bandying “J2EE” (and related “techologies” e.g. JSP, JPA, JNDI, etc) around on their resumes. All distributed systems, Java or otherwise, are governed by the same underlying rules of computational theory. Many software developers would do well to read a good text on distributed systems (perhaps Birman’s latest book “Distributed Systems” or the slightly older one of the same name by van Steen and Tanenbaum) before getting too bogged down in reading vendor whitepapers or “specification” documents.

Dave

Yury - you cite the example of eBay and their home-grown transaction management approach, but do you understand _why_ eBay made those technical decisions? Martin Fowler has a write-up on eBay’s “transactionless” approach (http://www.martinfowler.com/bliki/Transactionless.html) and Dan Pritchett’s InfoQ speaker page (with links to presentations) to which he refers is here: http://qcon.infoq.com/qcon/speakers/show_speaker.jsp?oid=175.

You do state in your post that “you can hardly understand the explanation” so I hope the above gives you some information. Maybe it’s best described like that old country & western song “Freedom ain’t free” - except we can say instead that: “2PC ain’t free” (2PC = two-phase commit) It isn’t, not for you, me or eBay. And when you’re running tens of thousands of database operations per second, the overhead of strict isolation and strong ACID compliance can begin to hurt!

And while I’m on about 2PC, check Gregor’s article, originally entitled “Starbucks doesn’t use 2 phase commit”. Quite illuminating

http://www.enterpriseintegrationpatterns.com/docs/IEEE_Software_Design_2PC.pdf

In fact, Gregor’s whole site is worth a long read. He was one of the most impressive speakers (IMO) at SpringOne 2006 in Antwerp.

Okay, stopping now - got _real_ (i.e. “for food”) work to do!

Dave

Agree with your sentiments. Just expressed something similar in email to Dan, part of which I will take the liberty of repeating below:

My little secret advice for finding a good developer is to look for one who programs in at least one “interesting” language, where “interesting” is defined to be one of: Perl (decreasingly, but it was my interesting language for a long while so I’ll include it), Python (the new sweet spot it seems), Ruby, Haskell, Erlang, Concurrent Clean, Stackless Python, etc. This tells you (at least) two things about the person: (1) the person is familiar with (1) the idea of learning a language “for fun” - which in turn tells you a lot about their motivations to be in the industry, and (2) that they have been exposed to programming ideas outside of the conventional “narrow box” thinking of C-like (yes, Java) statically typed procedural languages.

Now that doesn’t mean you’re expecting the person to be coding functors, monads, closures and higher order functions (”for food”, i.e. paid day-job) all day long, but take a bet that the kind of person who has been exposed to these concepts, *and* can also code a “day job language” like Java/J2EE is likely to be a lot better hire than someone who has not.

I also know what you mean about the “arse-about application” anti-pattern. Because the “servlet container” is the canonical “core” of the environment in the eyes of the (inexperienced) architect, they go ahead and build the whole damn app inside the thing. The app gets started via a ContextLoaderListener hook or some similar bullshit, and if you want to refresh some aspect of the UI contained in a servlet or jsp (you do have run-time compilation switched off for performance, right? lol) then it’s a matter of taking the whole damn thing down to do so. Truly crazy stuff, but it comes with the territory it seems. Clearly a separation of concerns argument would have the UI tier and the processing tier in separate application contexts (and the processing tier not, ideally, running inside a J2EE app-server enviironment at all). I think the Spring guys, Adrian Colyer in particular, are starting to head this way with the talk of OSGI support and integration, but there is some way to go just yet.

– Dave

I almost forgot, apparently if you use Tomcat to put a couple of JSPs then you’re building a J2EE application and Tomcat is an application server. Back in the old days (1999) Tomcat was a servlet container.

I know of a couple of aberrant architectures because of doing it in an app server (aka Tomcat). The application is a server that listens for SMS through a SMPP channel, that’s the main purpose, but since the application had a web service interface to query for transactions then someone decided to transform that into a web application!!! So now the server is embedded in Tomcat instead of embedding Jetty or Simple within the server!!!

We develop gateways and systems that interconnect other systems, an app server is too much, too bloated for our needs, we need control, we need to know what’s going on in our application.

Sorry for the long post, but it’s kind of comforting to see that there are people somewhere that think as I do and have the same problems as I do.

If you find a way to attract real devs, please share it with us. I will do the same if I succeed.

As always, one must use the right tool for the problem…

Spot on with the FLP thing - one nit pick which is that Patterson should be Paterson (at least according to all the history I can find) though there are mis-spellings around the web.

So I owe you some beer tokens - I sometimes get to Sydney and If you’re ever in the UK I’m buying.

Good stuff,

Dan.

“I think I’ve been a victim of J2EE success”

It sounds like you’re sorting out a cure though

Seriously just remember it’s not just about the technology (though I think Python and Django are worth spending time with) it’s the thinking - your design philosophy, your architectural approach, taste, simplicity, pragmatism, a global view that covers the whole lifecycle including deployment, treating ops as customers etc.

Good luck!

Dan,

– D.

I think this is what you’re after: http://portal.acm.org/citation.cfm?id=214121

FLP is a classic paper on impossibility of consensus in distributed systems.

To Dan:

Agree 100% with your post. Quite spot on, though you seem to have stirred up the Java-monkeys at TSS just a little

– Dave

J2EE was supposed to solve all the hard problems for developers. The major ones. Transactions, security, remoting. That is fine. But for 95% of applications, this kind of architecture is overkill. It was sold as something you do so that you’ll be able to scale in the future. However, the fact that the biggest sites are moving away from J2EE at the super-high end tells me something: J2EE is not necessary at that scale.

So J2EE is now not required at the high end, and a pain at the low end. Is there a sweet spot in the middle? I’m not sure.

I’m learning Python and Django. I’m learning more about Unix. For too long I’ve just been staring at the Java JSRs and I didn’t understand that when doing maintenance, Operations and Reporting have to be easy.

I agree with much of what you say but would contend that learning new technologies and languages is only the beginning. Understanding higher level issues around design, architecture, performance etc is where the real value is at though it should be underpinned with a grounding in various tech.

At the moment I think too many are tech magpies that eschew the higher level thinking. And as I’ve said in several comments, the motivation for the entry is to determine how best to locate those that think at or aspire to be at this higher level.

I’ve learned a lot from J2EE. I can’t think of a reason I’d want to use it today. But I sure did a few years back. But isn’t that the case for just about every technology? You should keep pressing on, learn new techniques, languages, etc. I find that to be quite fun, challenging and rewarding.

“Perhaps my level is not high enough but I can not understand why adding servers to J2EE cluster is bad for scaling?”

If your load is read-only and you can afford to be loosely consistent then adding boxes is fine. Scenarios outside of this profile need other strategies (or at least a mixture).

“I think the problem you mention is not J2EE specific.”

Indeed however J2EE’s wide reach exaggerates any “bad” side effects such as “wrong-thinking” well beyond what other technologies might do.

“Instead eBay developers do things “properly” they update “important” tables first and in case of troubles they know how to clean them up. Well as J2EE developer I can hardly understend such explanation”

For a hint as to what’s going on here see:

http://www.dancres.org/blitzblog/2007/04/12/when-is-a-transaction-not-a-transaction/

And check out the eBay presentation:

http://www.addsimplicity.com.nyud.net:8080/downloads/eBaySDForum2006-11-29.pdf