Personally, if I were a good technologist (not a code monkey or a manager) _and_ I knew exactly what I am after, I would start with good but basic infra like Caucho Resin and build the rest myself. J2EE is so layered, it's very hard to know what's going on inside unless you are a J2EE maven, which kinds of defeats its stated purpose (namely, to allow non-specialists to build "enterprise-class" web apps with relative ease).

Why use Java anyway? Have you tried playing with Erlang?

Is J2EE's stated purpose to allow non-specialists to build "enterprise-class" web apps with relative ease? I think the post by Cameron Purdy puts paid to that - his very definition indicates that this is a non-specialist need:

> However, "enterprise" applications often have more than one RM, and in
> fact that is what qualifies the applications as being "enterprise" -- the
> fact that they have to glue together lots of ugly crap from previous
> "enterprise" applications that in turn glued together ugly crap from
> previous generations and so-on.

I haven't looked at Caucho Resin, how does it compare (to JBoss) ?

The reason for not looking at Erlang is that it hasn't got wide-spread support. When it comes to writing big systems over many years, you do have to choose something that's got legs. GH chose Java for us in 1995 and it was a good choice; there are few competitors that support big systems, are easy to program and have wide support.

>Is J2EE's stated purpose to allow non-specialists to build
> "enterprise-class" web apps with relative ease?

That's how I read it. You can implement the recoverability features described by Purdy's post with a home-grown scheme but that may give you gray hairs.

However my comment on building it yourself assumed you have a relatively simple application and no legacy bits. The point is that as long it doesn't take you longer to implement something yourself, building is always better than buying if the penalty for failure is severe because, first, when you buy usually you don't understand what is going on inside the software and, second, the way software licensing contracts are written, you'll have no recourse for damages incured when using the 3rd-party software, even if it was buggy.

>> I haven't looked at Caucho Resin, how does it compare (to JBoss) ?

It's just a servlet processor. It seems I had misunderstood your application needs: for db stuff, Resin will not help you.

>> The reason for not looking at Erlang is that it hasn't got widespread
>> support.

I think that's a fantasy. Erlang is used at Ericsson for mission-critical systems and you can buy support from Ericsson and various consultancies. True, it is nowhere as widespread as Java but it has a growing community of real-world users and it is not an academic fringe language.

-- O.L.

the benefit of so called widespread support is vastly overrated. I have a decent amount of experience with J2EE and Java in general and still prefer to build systems with Smalltalk. Smalltalk does not have as widespread support as Java does, but it is modern and powerful and had been quite successful in delivering enterprise solutions for quite a number of years and has a strong community of real users. The idea that Java is the end all only benefits big companies like Sun and IBM. There are a number of viable technologies out there that have some real advantages over so called "widely" supported technologies such as J2EE.