Despite the two puff pieces this
week that serve marketing needs rather than offer up journalistic
balance and serve to educate, two modern computing myths are slowly
crumbling under the weight of reality. The two myths are:
 The myth that
Eclipse is fast, NetBeans
is slow and
its corollary
myth that SWT is fast, Swing is slow. |
These two myths have at been at the core of the marketing
drumbeat emanating from IBM/Eclipse Foundation. With the hype
from EclipseCon 2005 in high
gear it is finding its way into articles that pass as journalism - one
of which has been thouroughly
disected and discussed on JavaLobby.
| The realities
are
something different than the IBM
marketing and advertising dollars can buy and the current trends do not
bode especially well for Eclipse. Successive versions of Eclipse
have become slower and more resource hungry than predecessors and
each new version of NetBeans since 3.5 has been faster. This
has become a serious concern and the Eclipse organization is working on
usability while at the same time facing increasingly fierce criticism
not only on the issue of performance but also for the weak
performance and reliability |
[NetBeans] Very fast (at least,
on Linux, it is way
faster than
Eclipse, and
I would be tempted to say that it should approach Eclipse on
Windows...)......
I did not think I'd be saying this, but it don't seem like I'll be
switching back...
- An Eclipse Developer
on NetBeans
|
of Eclipse on non-Windows platforms. Meanwhile,
Swing-based development environments such as NetBeans 4.1 and IntelliJ
IDEA have shown that not only is Swing capable of providing great
performance but it does so and at the same time offers features that
are highly competitive and in some cases absent from Eclipse. The
once forebidding NetBeans user interface has been transformed into what
one developer describes as a
much more "intuitive interface" [than Eclipse]. The result is that many Eclipse developers
have switched to NetBeans and others are beginning the migration to
NetBeans by using both IDEs. Though the Java and Eclipse
forums are littered with "why is Eclipse slow", "why does Eclipse
freeze for 25 seconds" , "crashes" and a number of like questions,
increasingly it is becoming more obvious that perhaps the problem may
not be just Eclipse's architecture but also that SWT is only
optimized on Windows and is not the fast performer that its proponents
suggest - a number of observers have mentioned this. Has it all
been worth it ? SWT development has been a huge, unnecessary cost
that Eclipse Foundation members have the burden of sharing. They
have managed to implemented about a third of Java2D and have just
discovered the merits of deferred layout. With a little push -
SWT will be where AWT was 7 years ago. All of this and
Eclipse is tasting a serious backlash from Eclipse users :
On Linux, without SWTFox (
http://swtfox.sf.net ) its so lame that its really disgusting even on
my 2.6ghz/p4.
The GTK interface is
eating CPU withought any end and is really unresponsible.
Even opening menues cases
gray boxes everywhere, scrolling through menus or using the editor is
just pain.
Netbeans-4.0 has a about
3-5x faster GUI!
...however I learn
eclipse and do not want to change all my projects...
- see Clemen's entire entry here on JavaLobby
|
Eclipse is definately slow. Throwing lots
of memory and cpu at it helps but doesn't entirely fix it. I have a
3GHZ p4 with hyperthreading, a sata disk and 1GB of memory. That should
be more than enough but it isn't.
- see Jilles entire entry here
on JavaLobby
|
Well, I tried to use it several times, but
its soo extremly ugly that I could not resist to switch back to GTK
again.
I do not understand why
they do provide a motif-version at all
- it looks like crap it feels like crap and most widgets need to be
emulated cause motif is soo old that it lacks many features.
I think they want to make
the 100 devs happy that use Eclipse on AIX/PowerPC.
Well, native does not
always mean better - IBM has proven SUNs theory.
- Developer on trying to use Eclipse with Motif -from JavaLobby entry
|
I have seen developers pulling their hair
out over this performance issue alone.
Having watched this issue dragging on for more than a year it
convinced me that SWT is a major design flaw and I congratulate Sun by
going their own way with Netbeans.
- See John's
entire entry here on JavaLobby
|
It is worth reading the JavaLobby entry
of John Zoetebier who does a nice job of getting to the heart of the
problem which is that "SWT Widgets are a design flaw" - he mentions the
large performance gap between Eclipse on Windows and non-Windows
platforms and points out that this has been reported as a bug. The
Eclipse bug report John mentions makes for interesting reading.
I encourage anyone running Eclipse on Linux to read it.
A snippet of what Eclipse/Linux users are correctly upset about :
...The current GTK2-port looks like a
really big hack around features GTK2 simple doesn't have....
...Windows clearly outperforming the
others. Improvements made to SWT alone have not reduced this
"performance gap" enough...
...On Linux SWT only causes problems, the
only advantage is, that it has is the native look&feel, however
there are so many toolkits out there a native l&f even doesn't
exist on this platform...
...Just to give IBM an understanding of
the gravity of this bug, this bug report has gotten people talking
about getting a SWT->Swing port complete just to run Eclipse faster;
could anything be more ironic than that ?...
- To get the flavor of the issues Eclipse
is faced with, please read the
whole page.
John's entry in JavaLobby goes to the
heart of the
problems that Eclipse faces and why NetBeans and other
Swing-based
IDEs are showing faster speed-ups vis-a-vis Eclipse.
|
The bottom line is that if you are on Linux you are better off running
NetBeans. From the descriptions you can see the severity of
Eclipse's SWT/Linux problem.
R.J.
Lorimer JavaLobby's entry is a
look at Eclipse and SWT comments :
I
have never fully understood IBMs decision to implement SWT rather
than use Swing. The only thing I could come up with was the need to
have total control over the development process (Eclipse says jump, the
SWT team says how high?).
That's total speculation of course; I just have rarely seen
the power of SWT over Swing personified in a real-world example. I
won't argue that both have their disadvantages (SWT is much harder to
customize, Swing is much harder to integrate with native concepts such
as directory choosers and menu dropdowns). Either way, neither is a
silver bullet, and if I could be convinced that Sun was finally mending
their ways, my vote would be on Swing.
-see the complete entry here within
the context of entry 1 and 2
|
Lest you think this is just an unsubstantiated opinion - consider this
longtime Eclipse Linux user who was impressed enough to write the
following about NetBeans :
Very fast (at least, on Linux, it is way
faster than Eclipse, and
I would be tempted to say that it should approach Eclipse on
Windows...). Very stable too, responsive. They've revamped it (copied
the project perspective from Eclipse), so you're not lost.
I did not think I'd be saying this, but it don't seem like I'll be
switching back...
-see the complete entry here, Yannick's "Converting...to NetBeans entry
|
Remember, IBM, in theory, built SWT because they said it would be
faster than
Swing. They also claimed better native toolkit fidelity. Now
Eclipse is saddled with a headache. SWT is not part of
the standard J2SE. SWT from platform to platform shows itself to
vary in reliability and performance. In some cases, Eclipse's own
developers are confronting the obvious case that Swing is outperforming
SWT especially on Linux systems. And in order to add new
functionality more of the complexity that SWT was supposedly avoiding
is being tacked in. The result isn't pretty. SWT on Linux
is not
performing well or at least consistently - and Swing is out-performing
SWT
or showing itself to be at least on par.
It It has been over a year and half since I posted a comparison of SWT
and Swing and over three years since Eclipse and SWT was
released. Swing adoption continues, its growth aided by
considerably faster JVMs, higher quality Swing releases and overall
better Swing tools including new ways of debugging clientside Swing
applications. SWT adoption for applications really never seems to have
happened. Those that wanted SWT to be more than a way to create
modules for Eclipse have to be extremely disappointed, and
probably a bit stunned, with the very, very few applications written in
SWT. The SWT community page
can only come up with four
applications (that's right - count them - only four !) under the "Games
and Applications" in SWT Community Page. And of the four Azureus
is the only one that is popular. They forgot to include
Eclipse and Haystack. Another SWT related-site, onEclipse, does a
better job of detailing SWT applications
and can only come up with a total of twelve applications - a tiny, tiny
number after three plus years of SWT. Compare this with Swing Sightings,
which is a very, very small subset of the Swing applications.
SWT usage as vehicle for building non-Eclipse-related applications is
almost non-existent. I suspect that Thinlets or even Microsoft's
ancient WFC
toolkit are probably more popular when it comes to the applications
that have been created using these two toolkits.
Developers are switching to NetBeans. How ? Another NetBeans 4.1
Beta feature that is making it extremely easy is NetBeans ability to
import Eclipse projects. See the switch page
and import page.
Competition has been very good for NetBeans. The NetBeans team
has taken a serious interest in creating the most competitive IDE they
can - they have completely transformed NetBeans into a fast,
user-friendly and feature-rich development environment.
Developers are noticing... and migrating to the latest version.
You can evaluate NetBeans by visiting the main
NetBeans site
and downloading the latest version - I recommend NetBeans
4.1 Beta and if you want to import your Eclipse projects, look here.
While your at it - download the NetBeans
Profiler to profile your apps.
While some of the media has focused on the nice-looking exterior of the
Eclipse house and how many occupants are waving from the second floor
balcony, few people have noticed that the interior of the house's
first floor is on fire and people are leaving via the backdoor.
Now you know why Eclipse developers are starting to switch.
|
