Eclipse RCP offers a wide variety of features for the application developer. First, it offers a semantically complete and durable component model based on the OSGi bundles standard. The Workbench provides an application shell that developers can plug perspectives, editors, and views into. There are facilities and frameworks for building editors, help facilities, welcome pages, and defining resources.

The best part about the RCP is that it is very real and it is here now. Developers who are interested in using Java on the desktop don't have to wait for Mustang. Developers who are concerned about platform lock-in don't have to wait until whenever Longhorn ships. RCP enables multi-platform rich client application development now.

RCP has been around for about a year. The big news with 3.1 is really the improvement in tools. The Eclipse Visual Editor now supports the ability to create Eclipse editors using SWT. The Plug-in Development Environment (PDE) has been improved to make it easier to create and deploy Eclipse rich-client applications.

And in case you're wondering, RCP is not just about SWT. You can build RCP applications that utilize Swing. For the Eclipse community, the Swing versus SWT debate is uninteresting. This is not a religious debate. It's about picking the best tool for the job at hand. For those enterprise developers and ISVs who want to build applications with a native look and feel, SWT is a great framework. For those who are less concerned about platform fidelity, we support Swing.

JDJ: With the goal of building out tools for the entire software life cycle, where will the commercial vendors be left to compete? Is there a tension between having the whole life cycle tooled and the vendors that are strategic developers currently competing on that level?

MM: Eclipse is not about supplanting commercial opportunity. It's about creating it.

It's a common misconception that Eclipse is about building tools. That is not the primary focus of our community.

The main objective of Eclipse is to create a universal development platform made up of frameworks and well-constructed APIs. Then we provide exemplary and extensible tools to demonstrate the use of the frameworks. But the point of this work is to build a platform on which vendors can implement their products. The tools are extensible so they can be further customized to meet the specific needs of commercial platforms.

Now many developers are perfectly happy to construct their toolset on top of Eclipse and open source plug-ins. In the case of our Java development tools, the adoption rate is impressive. But the majority of enterprise development shops are going to be looking for commercially supported and tested tool chains.

JDJ: Turning to Swing/SWT interoperability, can you describe where it is and where it's going?

MM: I really haven't seen a lot of new Swing/SWT interoperability features in Eclipse 3.1. Most of the feedback from our community has been that what we already have is pretty great.

JDJ: Speaking of SWT, do you still think it's worthwhile to try to get cross-platform consistency from native code? Given that all this work has already been done for Swing, do you feel that SWT is still a good bet? Is it wise to repeat work that has been done for so many years in the Java code base?

MM: Of course it is. Java is a great programming language. But the idea that Java should be constrained to only fit one style of application and one way of doing things is just lame. SWT has never been about supplanting Swing. It has been about providing a realistic and high-performance alternative for people whose application requirements demand it.

We believe that there are probably many more Swing applications being built with Eclipse than any other toolset.

The comment about "repeating work" is inaccurate. Swing continues to get better at emulating platforms, which is fundamentally different than the SWT strategy. We are not repeating work. We are implementing an alternative strategy for implementing GUIs with Java.

I believe that the competition from SWT has done more than any other factor to improve Swing. Competition is good. Choice is good. SWT is here to stay.

JDJ: Now that the RCP is well established with the release of 3.1, what direction will Eclipse be headed in the 4.0 time frame?

MM: Instead of talking about a specific release, let me talk about what we want to focus on in the next 12-18 months. A lot of this will be driven by the themes and priorities in our development roadmap. Some of the highlights will include:

1. Continue the evolution and adoption of RCP. We believe the technology around RCP is mature and real now. The focus needs to be on developing frameworks for RCP and having applications adopt RCP as their development platform.
2. Expect to see a lot of work and emphasis on providing tools and frameworks for the embedded developer. We have just launched a new Device Software Development Platform project and I think you'll see some great stuff coming from it over the next 12-18 months.
3. We will continue to extend the set of projects across the software development life cycle
4. Finally, all of the projects are focused on ensuring their tools and frameworks can scale to meet the usability and performance challenges of enterprise development, including support for lots of code and lots of developers.