Eclipse casts shadows

Conspiracy theorists love the Eclipse project. When the IBM-led consortium launched its open source tools framework last fall, tongues began to wag. Not only does Eclipse shun Java’s standard AWT (Abstract Window Toolkit) and Swing libraries, replacing these with SWT (Standard Widget Toolkit) for basic widgetry and JFace for advanced effects, but the Eclipse’s very existence challenges the Sun-backed open source tools framework, NetBeans. Recent Eclipse announcements from IBM make it clear that Eclipse will host IBM’s middleware tools as comprehensively as NetBeans does Sun’s. Does Eclipse represent a two-front assault on Sun’s Java stewardship? Yes and no.

What almost nobody disputes is that Eclipse is hot stuff. The Version 2.0 build we tested shows that Java can indeed produce a major-league application that is comparable to Visual Studio .Net and that is both speedy and faithful to the Windows GUI (graphical user interface), which even most J2EE (Java 2 Platform, Enterprise Edition) developers prefer. The SWT/JFace underpinnings partly explain why. AWT’s encapsulation of native operating system widgets is opaque, says Chris Grindstaff, a senior member at Overland, Kan.-based Applied Reasoning and a former VisualAge developer. In other words, the code that interacts directly with the native widgets is written in C and is not directly available to Swing. Eclipse’s SWT, by contrast, encapsulates the native OS transparently, using a one-to-one mapping from Java to C. That means Eclipse’s JFace layer can more flexibly exploit the native widgets.

SWT detractors argue that this approach trades away Swing’s universality. By painting its own widgetry on a handful of core primitives, Swing can be the same everywhere. It’s an old debate, but Java’s failure to thrive on the Windows desktop underscores just how much the market cares about native look and feel. It’s true that SWT is not yet available everywhere. But Eclipse 2.0 works with Windows, Motif, and GTK+ (Gimp Toolkit) 2, and operability on Mac OS X seems imminent. Unlike Swing-based software, Eclipse works immediately with native features such as Windows XP skinning. “Microsoft has lots of programmers and so does Gnome/GTK,” Grindstaff says. “So why not leverage that?”

Eclipse, however, owes its strength to more than just SWT/JFace technology. The primary developer of Eclipse, Object Technology International (OTI), has for many years been refining the arts of the componentized IDE (integrated development environment)—Smalltalk/Envy, VisualAge for Java—and the portable GUI. The current AWT/Swing vs. SWT/JFace debate recapitulates an earlier tug-of-war between the ParcPlace (emulated GUI) and DigiTalk (native GUI) flavors of Smalltalk. OTI favored the latter approach, which prevailed. Should Sun have done likewise with Java, as by several accounts OTI proposed to Sun years ago? A growing number of voices are now saying so.

Such hindsight is, of course, useless to vendors heavily invested in Swing. “Eclipse clearly does nice things, especially for Windows,” says Steve Benfield, CTO of SilverStream in Billerica, Mass. But his products’ use of Swing precludes support for Eclipse. Does that matter? Perhaps not much, Benfield suggests, because SilverStream’s tools target business application developers more than hard-core J2EE coders. It’s a good point. Seamless tool integration—the hallmark of both Eclipse and NetBeans—is a sexy feature, but a common UI alone can’t bridge different cultures.

But vendors whose products align more closely with the core development life cycle can’t avoid the issue. Consider Merant. From the perspective of its version control system, PCVS, there are three platforms at which to target plug-ins: Visual Studio .Net, Eclipse, and NetBeans. The .Net plug-in was a given. In the J2EE space, Merant chose Eclipse—and joined the Eclipse consortium—because that’s what customers ask for, according to Patrick Merrit, senior product manager at Merant in Hillsboro, Ore.

Notably absent from the Eclipse bandwagon is BEA Systems. “If you’re going to break a standard, you have to be 10 times better,” says George Snelling, director of engineering at BEA in San Jose, Calif. He contends that success with Swing merely requires brainpower and talent that have not often been used to crack the nut of the Java GUI. Marc Loy, coauthor of O’Reilly’s Java Swing, concurs. “If Swing could be built on top of an improved AWT [that is, SWT], we’d have our gold standard,” Loy adds.

BEA’s WebLogic Workshop is a Swing application built neither on Eclipse nor on NetBeans. Would an SWT-based Swing be attractive? BEA’s Snelling doesn’t much care. “If Sun decides to make their development life easier by switching to SWT, that’s up to them,” he says. In broader terms, Snelling questions Eclipse’s premise: to be, as the project’s FAQ puts it, “an extensible IDE for anything and yet nothing in particular.” Tools such as Visual Studio .Net succeed, he argues, by delivering core functionality, not by merely hosting best-of-breed plug-ins.

An IDE framework for J2EE plug-in tools is clearly a good idea. “It’s no surprise that IBM came along and copied our [NetBeans] approach since it’s the correct one,” says Drew Engstrom, product line manager for Sun ONE (Open Net Environment) Studio at Sun Microsystems in Palo Alto, Calif. IBM’s Scott Hebner, director of WebSphere marketing, says that “Eclipse had nothing to do with Sun” but that the competitive target was Microsoft. In any case, both are open source projects in which Sun and IBM represent themselves as minority interests. “It’s beyond us,” says Armonk, N.Y.-based IBM’s Skip McGaughey, the Eclipse chairperson, who adds that the community of programmers “will vote with their keyboards to solve the problems that are important for them to solve.”

Regardless of the degree of control Sun and IBM exercise in those communities, it’s not clear that either Eclipse or NetBeans solves a first-order problem. IDEs come and go. The ultimate tool framework always was, and may still remain, emacs. Of greater importance is the viability of Java on the Windows desktop and on smaller devices that simply can’t push Swing’s many layers.

Whether by accident or intent, IBM’s involvement with Eclipse and SWT is an assertion of Java leadership. Many welcome this but would prefer that IBM acknowledge the reality and submit SWT to the JCP (Java Community Process). “If it’s good for Java, let’s get it out in the open,” Sun’s Engstrom says.

“We could work out a collaborative arrangement with the Sun process,” IBM’s McGaughey says. In other words, it’s a standoff. This will inconvenience some vendors needing to integrate with both Sun’s and IBM’s product lines, but it won’t matter in broader terms. What matters more is the underlying SWT/AWT issue. If IBM and Sun can find common ground, within the JCP and otherwise, by all means hurry up and do so. Time flies.

Source: www.infoworld.com