The Hurricane Called Eclipse

One of the most intriguing presentations at Java Pro Live! was the keynote by Mike Milinkovich, executive director of the Eclipse Foundation. He spoke on what Eclipse is and what it will become in the future. While a few in the audience thought it a blatant product pitch, my sense was that most were interested in just what was this thing that everyone had come to think of as a freely downloadable, if less full-featured, development environment.

But I learned that Eclipse is much more than that. Unfortunately, its story isn't told well by the Eclipse Web site (www.eclipse.org), and its origins as that development environment just keep perpetuating. It is true that just about everyone who uses Eclipse does so as an IDE, but that will change in the future.

Why? Today Eclipse bills itself as "an environment for everything and nothing in particular." What it is, in fact, is a universal framework. Think of it as a container, for a compiler, editor, and debugger, for example. The interesting thing is the container can hold anything, and is free for any use. And the container enables its contents to do things that they might not have been able to do in the past, such as copy and paste. At the very least, it makes those types of tasks easier.

You might expect the rush to Eclipse to be led by developers of the open source and freeware tools, and there is some logic to that. Many of these tools are very functional, but have only the most basic of user interfaces, often only usable from the command line. It is simply easier for the developers of these tools to add a graphical user interface by making them Eclipse plug-ins.

But commercial vendors are starting to take notice, too. In addition to IBM/Rational, tools providers like Borland, Flashline, and Micro Focus have joined the Eclipse Foundation. At the very least, they are adapting existing tools to be available as Eclipse plug-ins. In other cases, they are using Eclipse as the platform on which to build a more comprehensive application lifecycle set of tools.

The growing acceptance of Eclipse represents the next step in the evolution of application lifecycle tools. You can assemble free or commercial tools based on the "best of breed" concept, and use them together as your development environment. If they are Eclipse plug-ins, you have the added advantage of a similar look and feel, and a similar way of using them, even if they were developed by different people for different purposes. The IDE can consist of tools from a variety of vendors, all integrated simply by being Eclipse plug-ins. The integration isn't likely to be total, because the tools might not be able to share data, but they can more easily be used together.

And the use of Eclipse goes far beyond simply development tools. There is no reason why it cannot play the same role for testing tools and application and network monitoring tools. Look for Eclipse to be both a test management platform as well as a monitoring console.

Eclipse will end up changing the entire direction of application lifecycle tools, and it's not possible to guess what the outcome will be. Project Hyades, for example, is an integrated test, trace, and monitoring environment based on Eclipse. Other Eclipse projects support graphical editing, tools generation, and UML. Commercial vendors and free tools developers have to look at what Eclipse is offering and make some honest decisions about just how their tools add value beyond it.

If there is still significant value in the existing tool, it will likely migrate to an Eclipse plug-in. Unfortunately, if the amount of value remaining is "not much," then the tool will probably be superceded by the Eclipse platform and one or more of its collateral projects. Either way, the ground under the tools vendors is shifting.

Posted by Peter Varhol on 10/31/2004