One of the things that programmers like about J2EE is the availability of declarative transactions.
Adam Bosworth, an architect at BEA, writes in a paper on the future of messaging technology:
Alan Kay is supposed to have said that simple things should be simple and hard things should be possible. It has been my experience over 25 years of software development that for most software products, simple things should be declarative and/or visual and hard things should be procedural.
[The added emphasis is mine.]
I came across the original saying — simple things should be simple and hard things should be possible — as a motto for Perl. It seems to me this variant is also a good design guideline. I especially like the remark immediately following it:
Declarative languages have an unfortunate tendency to metastasize because people need to do things that are hard. When they grow in this way, not only can most people not use these new features, they find the entire language more daunting. A good example of this is XSLT.
Transactions are hard are hard to understand conceptually and even harder to implement. However, for the J2EE transaction declaration, the domain is small. You choose your transaction type and that is it.
It is a boon to be able to declare (or configure) the behaviour you want instead of programming explicitly. Less code means fewer bugs. However, when it goes beyond covering a few common cases, a declarative language loses its advantage of being easy to learn and easy to apply.
(The rest of the paper is worth a read. I think he's wrong to say we want push technology for our mobile devices. Clay Shirky has the right insight, I think, in his article debunking the notion that grid computing is the next big thing: when faced with poor connectivity, people prefer to get better connectivity rather than give up control. Besides, who really wants to get spam on their mobile phone?)