website stat

Eclipse: Best.. Java.. IDE. Point.

I didn’t remember how cool Eclipse was. Actually, it has become even better and branch 3.x really turns out to be (IMHO) the best IDE/RCP (Rich Client Plataform) out there.

Why? Well, first of all, it doesn’t use Swing. Yes, it does not consume 400MB RAM for running (but it still memory-hungry). It is built upon SWT, a wrapper that uses the graphical API of each operating system instead of Swing. It is compiled from native code and does not get slowed by a virtual machine. So in GNU/Linux it makes use of GTK, in Windows GDI/Windows.Forms, Mac OS X it’s Carbon/Cocoa, etc.. You may be wondering: “But hey, how about interoperability? The other operating systems?” Well, including the SWT framework on your package costs you nothing more than 1/2 MB. But you have to pray that the SWT is already ported to your target OS.

Besides using SWT — which is already a lot — it has tons of useful plugins that ease, a lot, your work. Visual editors, UML, powerful refactoring, CVS/SVN, etc, etc.. It’s endless. Last but not least, it’s Free Software (despite not being compatible with GPL).

If you haven’t tried Eclipse already, give it a chance. You won’t be disapointed.


9 Responses to “Eclipse: Best.. Java.. IDE. Point.”

  1. CPinto
    Published at September 29th, 2005 at 2:21 pm

    First of all, Swing has absolutely nothing to do with memory consumption.

    Eclipse is a bigger memory hog than, say, IntelliJ and JetBrains’ IDE is fully Swing-based, a lot faster and has a smaller memory footprint compared to that of Eclipse.

    Second, Eclipse isn’t native… I mean, some RedHat folks managed to compile Eclipse with gcj to a native binary but it crashes a lot.

    Therefore, whatever “sluginess” you notice in a tipical Java application, you’ll notice in Eclipse.

  2. mlopes
    Published at September 29th, 2005 at 2:29 pm

    Well, maybe I didn’t made myself clear. What consumes memory is Java by himself, not Swing. Swing is responsible for the slowness of the GUI and how much time it takes to answer to a mouse event.

    I didn’t say Eclipse is native. I said SWT makes use of native widgets :-)

    About gcj.. there’s no way of running a large web application with that. Crashes a lot, somethings (most of them) don’t work, etc.. Sun JRE or JDK is highly recommended.

  3. Nuno
    Published at September 29th, 2005 at 2:32 pm

    What about those operating-systems ? Gee dude, they’re such memory hogs! Like, on my laptop the OS takes out 120MB of RAM as soon as it boots! I so wish people didn’t need these operating-system thingies.

  4. mlopes
    Published at September 29th, 2005 at 2:37 pm

    @Nuno:

    Like it or not, Java is memory hog. Memory’s price is getting lower but still it takes a good machine to run decently a big Java program, like an IDE. Otherwise, swap won’t stop (well, fortunately hard drives are getting more silent and faster…)

  5. Carlos Rodrigues
    Published at September 29th, 2005 at 4:10 pm

    Swing doesn’t have to be slow. The problem is: Swing developers should stop throwing bloat into event handlers. The UI isn’t updated until the event handler method returns, but people insist on doing stuff there instead of having a separate “worker” thread.

    This is a problem with most GUI toolkits, but seems to run rampant on Swing.

    I’ve seen sluggish SWT applications (Azureus) and fast Swing applications (jEdit), so I don’t do much cheering for SWT.

    Besides, Swing runs everywhere requiring only a standard JRE, and has a much more consistent look (albeit non-native) than SWT (which seems to look just different enough from native apps to feel “wrong” somehow).

  6. mlopes
    Published at September 29th, 2005 at 4:16 pm

    @Carlos:

    Well, as far as my experience goes, SWT apps look like any other app that uses native widgets, be it on Windows, GNU/Linux or Mac OS X. The only plataform where Swing feels like native is on Mac because Apple has changed the JRE to use Cocoa instead of Swing widgets.

    If Azureus feels weird to you that’s because it makes use of Eclipse Rich Client Plataform which has a very custom design (not necessarily due to SWT).

    Regarding your comment about the problem being on the event handlers: NetBeans/Sun ONE Studio is slow as HELL (sic) and it was developed by them (Sun). Shouldn’t they know this fact?

  7. Carlos Rodrigues
    Published at September 29th, 2005 at 10:39 pm

    SWT has a few minor visual glitches that break the native look: on Windows, normal buttons, radio buttons, checkboxes and combo boxes don’t look native (they don’t use the system theme). I rather have a totally alien look than a look that tries to look native and falls short.

    That being said, I do like Eclipse, and it doesn’t look bad. But I’d rather use Swing than SWT for development.

  8. Personal Bytes » Blog Archive » Ruby on Eclipse!
    Published at October 18th, 2005 at 1:45 am

    […] Which again proves how nice Eclipse RCP is and how popular Ruby is becoming. […]

  9. Personal Bytes » Blog Archive » Stop wasting time with the middleware.
    Published at October 29th, 2005 at 5:13 pm

    […] And that’s where Eclipse RCP (Rich Client Plataform) gets in. It provides you with the best of Java and a lot more. SWT is also bundled in, so you can have native widgets on your application. I’ve already discussed very briefly the cons and pros of using SWT instead of Swing. But the best is yet to come. Eclipse RCP allows you to rapidly build the more common toolbars, menus and it also makes use of views and perspectives. A perspective has a set of views that can be moved inside the application. […]