Why? It's an admission that Java has had a lot of trends enforced that simply haven't worked, and won't work. I give you JavaBeans, EJBs, and a popular Web framework as examples.

JavaBeans were meant to be the drag-and-drop that brought the VB developers into the fold, with simple descriptions of use and parameters, easy deployment, and even state management. Lo and behold, now they're largely relegated to being a simple guideline for how methods and constructors should be built.

EJBs were the answer to distributed computing, with a promise of massive scalability. Soon, huge swaths of their specification were being avoided because of performance bottlenecks and complexity. Sure, you can get some of their promise out of session beans, and message-driven beans are easily my favorite aspect of the EJB spec, but getting good performance out of stateful beans or entities can be a fine art in and of itself.

Struts...oh, Struts. Tools for helping people build Struts applications can be found in every nook and cranny nowadays, and nobody questions why people are marketing tools and not components. If I want to build a simple process with Struts, I now have what seems like dozens of options to help me build that process, but who's willing to market a component to handle the process itself?

This strikes at the heart of the issue for me. Where are the components? There are reporting toolkits and some widgets for Swing, but where are the processes? Who's propagating knowledge of the EJB components that handle the gruntwork? Where are the Web services to allow the distribution of processes over nonhomogenous networks? Why are we still doing everything ourselves?

Until this can be answered, there's no way Sun has a chance to bring in all those developers. I know there are exceptions: Web services certainly do exist but, honestly, in my last five client installations, nobody mentioned them as an alternative even once, except as a nonviable one. I'm willing to admit that maybe I'm in a region that specializes in the "Not Invented Here" syndrome, but I don't think so - I've been at too many disparate clients for that.

What people are willing to invest in, financially or emotionally, are frameworks that still manage to leave the burden of work up to them. While that's comforting in the sense that I feel more valuable when I'm cranking out basic components (as opposed to simply tying components together), I think it's an underusage of the industry's capabilities. That means that we, as Java programmers, end up spinning our wheels in an attempt to be relevant, individually, instead of leveraging the very technology we've invested in.

After all, this is the stuff that J2EE was designed for: take specific functionality, allow it to be modular, and composite solutions together with ready-made tools. An EJB that processes an order can be written to handle a generic customer, a generic order, and a generic list of items, and can handle payment with a pluggable tool - and such an EJB, written well, would certainly be worth investing in instead of paying a developer to write yet another order-handling bean that can only accommodate the current requirements.

We still don't see it, though. I think this kind of sea change will be necessary, not just for J2EE, but for Java as a whole. At some point we have to stop falling in love with Java and start doing something with it. The capability is there. We just have to decide to imbue it with power.

It's time we started writing reusable components and distributing them. Otherwise, we as a community of developers end up squandering the power of the tools we have. Let's get to it.