[FR-devel] FYI -- Eclipse casts shadows

[Curt Hibbs]

Every software design effort involves tradeoffs, and how you prioritize
those tradeoffs depend on your (perceived) requirements. Even after all of
our extensive Rouge discussions I have to confess that I am still mightily
impressed with the design and implementation of Eclipse's SWT for Java.

Anyway, I thought you might be interested in this article from JavaWorld.

Curt

==========================================
http://www.javaworld.com/javaworld/jw-07-2002/jw-0705-iw-eclipse_p.html


Eclipse casts shadows
IBM-led consortium poses a challenge to Sun's stewardship of Java

Summary
The IBM-led Eclipse open source tools framework avoids Java's Swing
libraries in favor of its own Standard Widget Toolkit (SWT), which works
especially well in Windows environments. Eclipse also directly challenges
Sun Microsystems' NetBeans tools framework, not to mention Sun's stewardship
of Java. (900 words; July 5, 2002)

By Jon Udell, InfoWorld Test Center


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.


The Bottom Line - Eclipse and the future of Java

Executive Summary
The IBM-led Eclipse consortium has built a strong Java-based IDE framework
that works especially well on Windows, and Eclipse is attracting substantial
third-party support. But Eclipse's support for the (nonstandard) SWT, an
alternative to Java's low-level AWT, may matter most to the future of Java.

Test Center Perspective
Java's failure to thrive on the Windows desktop is a giant missed
opportunity, and the SWT technology at the core of the Eclipse framework
could help rectify this. If SWT can help to improve Swing, IBM and Sun
should pool resources and make it happen.