Other initiatives like JSR 198, whose goal is to describe a common API for extending IDEs, will benefit from interoperability. I hope I've seen the last newsgroup fan war between people who fight about which toolkit is superior. For those of you who are still arguing, Figure 1 shows an SWT shell with an SWT button on the left and a Swing button on the right. Or is it the other way around?

For everyone who isn't already doing so, let's all focus back on the real job of building killer apps for our users. This segues into my next subject - the buzz at EclipseCon around the rich client project. It's a concept seeded by Todd Williams of Genuitec and others in the community to strip Eclipse bare of all things that are related to its being an IDE, while leaving behind enough of its framework to allow wider-ranging end-user applications to still be built. In a way it has already begun, because SWT, which was built to be the GUI toolkit for Eclipse, is being used by some developers in their end-user Java applications. The rich client idea, however, is to go even further and allow programmers who are trying to create business applications to benefit from core Eclipse concepts such as perspectives, viewers, editors, toolbars, menus, wizards, and workbench state. I believe there is a huge potential for this to affect desktop software development.

The programmers who created NetBeans, JBuilder, IntelliJ, Eclipse, or whatever your favorite IDE is are some of the most skilled developers in Javaland and have undoubtedly created a whole set of class libraries and solved application problems that are applicable to anyone building a functional Java desktop program. The best frameworks come not from design committees architecting grandiose solutions buried in specware, but instead are harvested from successful real-world applications. These programs have proven their mettle by solving specific problems and then becoming refactored so that when similar issues are encountered again, the programmers don't have to start from square one and can benefit from the previous efforts. They will reuse the best parts of the original concepts and code and, in turn, provide feedback into the framework so it grows organically, with only the fittest parts surviving.

Michael Tiemann from Red Hat gave a keynote at EclipseCon where he discussed Moore's Law and the industries where it had been successful, as well as lamented why similar productivity gains hadn't occurred with software. In areas where Moore's Law worked, one of the key ingredients was that the output of a process was able to push back into itself, thereby creating an exponential feedback loop; for computer performance, once the transistor was put onto semiconductor programs that could then be written to allow chip designers to design the next generation of hardware, which then helped to speed the design of systems to build the next set of chips, and so forth.

Anyone building a business application for an IT department is unlikely to just start every time with the basic JFC (or SWT) class libraries. Instead they'll create frameworks that deal with navigation, validation, customization, user security, and other areas of program-ming as it doesn't make commercial sense to reinvent them each time a new department wants something built. I know programmers who, when leaving a company, try to negotiate a deal where they can take their class libraries with them. They view these libraries as part of their value-add that allows them to be productive elsewhere, the same way a skilled craftsman has a favorite set of tools. Some companies even create special framework groups to support their development efforts, although this has its dangers.

Why not have people building line-of-business applications just start with a set of high-level frameworks, and what better place to harvest this than from developers who have created the best-of-breed IDE tools? A colleague of mine once said that the best framework doesn't solve users' problems, rather it allows them to spend more time solving their real issues. In other words, it lets them focus on building their business application instead of on view management or implementing a weak observer pattern.

I hope all of the IDE developers take up this challenge and start to farm their neat stuff back into rich client product offerings. Perhaps then we can begin to achieve Moore's Law for software productivity.

• Figure 1