Simple
is a seductive notion. We all want to make things simple. But when we talk about software, simple
could mean at least two different things.
There are always two ways of looking at nontrivial software: the implementation view, and the user view. I have always gotten the impression (I may be wrong) that many people who say that J2EE is too complex
confuse the second view for the first. So, just in case I'm right about this, I think we should rephrase. Perhaps we should say J2EE is too /inconvenient/
.
A simple framework is very often /not/ the best solution to a difficult problem. Making life easy for developers does not mean giving us simple tools. The problem with J2EE development is not that the J2EE stack provides too much complex functionality; it is that the functionality is not exposed to the user in a convenient way.
For example, Hibernate is /much/ more complex (implementation-wise) than a CMP 2.1 entity bean container. Arguably, some of Hibernate's user-visible functionality is also more complex. For example, HQL has many more features than EJBQL and could therefore be said to be more complex. Likewise, Hibernate's support for multiple inheritance mapping strategies is a complex feature, not visible in CMP 2.1.
But it is that very complexity that makes Hibernate powerful, and, perhaps paradoxically, simplifies life for people using Hibernate to write applications. By contrast, CMP 2.1 is simultaneously too simple (featurewise) and too complex (from the point of view of the user).
The best frameworks are /powerful/, not simple. But they do try to get their internal complexity out of the face of the user, as far as possible. Sometimes it is possible, other times not. If you try to oversimplify a difficult problem, you end up making life more difficult for your users, who are then forced to work around your framework's limitations, instead of working with it.
There are very, very few simple solutions to difficult problems. Be very sceptical when someone claims to have found one.
