The Eclipse platform allows pluggable components — plug-ins — to help create a rich graphical user interface (GUI) application. With Eclipse you can enhance a user’s app experience by adding views to the GUI. This article will teach you how Eclipse makes it easy to link views and provides ways to adapt view linking to non-UI scenarios.
Wow, I can’t stand to look at that code; it’s so verbose and bloated. In any event, I figure it’s a decent article if you’re into that whole OOP thing for whatever reason.
-bytecoder
Ok, when I saw “The selection provider-selection listener paradigm”, I knew we were going to be in for some wheel reinventing. Then I saw “The property change listener paradigm”, and instantly knew that it went off the deep end of wheel reinventing a long time ago. Is it so hard to implement proper event handling in Java instead of constantly reinventing half-baked approaches? Then again, this is Eclipse, which fanboys will no doubt mindlessly fawn over.
Eclipse started as being an Java IDE and due to the success it had it has evolved a lot, becoming a Rich Client Plataform, where the Java IDE, and others, run.
So, Eclipse RCP is a plataform for developing your Java application. It provides you a lot of features, like perspectives and views in order to ease the programmers’s life. It uses its own GUI interface (SWT), instead of Swing. The differences being that SWT uses native widgets (only available for Mac OS X, Windows, Solaris and GNU/Linux) which means that it is damn faster than Swing. There are several comparasions about these two around the web.
Anyway, Eclipse RCP is definitely a great plataform to develop and deploy Java applications. Besides the obious IBM, also NASA (yes, the USA Spacial Agency) and several others (Azureus.. the bittorrent application), use Eclipse RCP. It is Free Software (although not compatible with GNU/GPL).
I’ve been talking about this subject and I also have a page dedicated to tricks&tips about Eclipse RCP. For those interesed, check http://gridpt1.fe.up.pt/mlopes/blog
“The differences being that SWT uses native widgets (only available for Mac OS X, Windows, Solaris and GNU/Linux) which means that it is damn faster than Swing.”
In theory. In practice, for whatever reason, it’s often slower than swing on non-windows systems. At least that’s been my experience. I do like it however, just for the fact that I’ve never seen a swing theme that I really liked as much as whatever I was using as my main system theme.
I have to agree with you. For some reason, under Mac OS X and GNU/Linux, it seems a little bit slow and slower then Windows. Swing is kind of equal in all plataforms.
Maybe SWT is not yet optimized for Mac OS X/Carbon and Linux/GTK.
I use both NetBeans (Swing based) and Eclipse (SWT based), and they’re about the same speed and load times in my experience. I run them on a 2.2GHz, 768meg RAM machine, and a 300MHz, 228meg RAM laptop (yes, amazingly enough, both of them run okay on that old hardware, so long as I use a lightweight desktop, like fluxbox or Xfce, a non bloated Linux distro – Mandrake in this case, and don’t try to run much else at the same time). And on both machines, NetBeans and Eclipse run at about the same speed.
Conventional wisdom says that SWT should be much faster, as it uses native widget tool kits. But, alas, SWT use Java object wrappers around the native tool kit, which does involve overhead. Also, Swing has come a long way. It’s not the slow hog it used to be, at least so long as the Swing using program is well written. I’ve been quite impressed lately with many Swing based apps – NetBeans, Limewire, jEdit, DrJava, HotJava Browser (from Sun), Sun Java System App Server Deployment tool, and others – they all look good, and perform quite well (albiet with somewhat slow load times – but that’s true of anything that loads a run time or entire GUI API, such as OpenOffice or Mozilla, which are C++ based).
I used to be a very loud critic of Java and Swing and J2EE for slowness, bloat, and complexity. But my opinion has been changed by using newer apps, and coding more with Java/J2EE. C and C++ won’t be beat for speed or minimum memory footprint, but Java/Swing/J2EE is doing quite well in that department, thank you very much. 🙂