Mike Clark and Glenn Vanderburg have been pondering J2EE's complexity.
Now, I've been buried up to my neck in J2EE for a while now, and from this position it's easy to loose sight of the big picture. We are using lots of neat toys, each of which helps me out in one way or another, so I'm happy to have them. Since they really do all help, I'm right to be happy.
El Presidente, though, looks upon this huge list with more than a little trepidation. And he's right too; we are using a lot of tools, many of which are fairly complex. By rights, our project is a fairly simple one. What do we need all this stuff for? (And we've kept the list as short as we comfortably can, believe me!)
Well, J2EE is at least part of the problem. A simple 'Hello World' application isn't, well, simple in J2EE. Servlets, JSPs, the deployment descriptor, the WAR file, the context, and so on.
You might argue that this is because J2EE isn't designed for simple applications. And you'd be right; it's designed for complex applications; it scales well. This is true up to a point. But. But if it scaled that well, we wouldn't need all this other stuff, would we? (An MVC framework, a persistence layer, additional taglibs, etc, etc, etc.)
(OK, so, I know that J2EE has its own persistence layer: EJBs. But I've been warned off them so many times I didn't even consider them. Also, The new JSP 2.0 includes the JSTL, removing much of the need for external taglibs.)
But the other side of the problem is Java itself. I think that at heart, Glenn has it right. Java is not amenable to extension, and J2EE extends it well beyond what ESR refers to as its 'functional envelope'.
Python doesn't have a J2EE, but if it did, I suspect that it would be far simpler.
Still, I can't say I'm not having fun with all this stuff, so it isn't all bad. ;-)