"The future of J2EE," indeed

In "The Future of J2EE," you find Tod Nielsen yammering about complexity in J2EE. What pap! He's a VP for BEA, and there's nothing wrong with that, except now he comes across as a snake-oil salesman... or one who doesn't understand the technology his company sells. J2EE needs to get simpler, he says. Yeah... uh, huh... really? I don't think so.

I don't think there's a lack of a market for someone selling tools to help perform various elements of the J2EE roles. BEA's own console, while annoying as ... oh, having someone tap on your shoulder repeatedly, certainly works for what it's intended for. That's a deployer tool, and it doesn't take a rocket scientist to work it out. If it's too complicated for people, perhaps it's time to change out the PEOPLE instead of the tool.

Does that sound elitist? It probably does. However, the role here is that of deployer, not developer. You should need very few admins compared to the number of developers a large shop needs. As such, it's okay that you want to concentrate on certain skills at that level... as if following a simple set of web pages is something you call "certain skills."

J2EE is simple. It's always been about giving you a lot of power for relatively little code. Can you outperform J2EE? Sure... by writing more code. JSP sucks... until you compare it to how that sort of thing used to be done. EJB is slow... but getting everything EJB does for you in your own code involves a lot of code. You can write your own grid solution, or a better messaging solution... but with simple old J2EE, you don't have to.

Come on, Mr. Nielsen. We have enough straw men as it is, and you have a valid enough point about the JCP without resorting to red herrings. Do better. We expect it.