Five years ago I looked at Eclipse and NetBeans as rich client platforms (RCPs) and thought both were crap for the purpose. Slow, ugly, immature, incomplete and bringing little but complexity to the table. I looked at both of them again anew last week.
The executive summary: both now look wonderful for Rich Client Platforms, you would need some pretty strong particular reasons to build your own framework now; Eclipse has the edge if your market is Java developers who probably have Eclipse already and your application can be made a suite-enhancing plug-in; Eclipse also has the edge if you want to provide a plug-in and a standalone version; NetBeans has the edge if you need Swing or all the OpenSorce libraries which use Swing—the wonderful SwiXML (which lets you specify Swing interfaces in XML, and uses reflection and the JavaBeans conventions to be very small and very fast) and the Substance look and feel library (whose Flamingo sub-project Topologi has contributed our BreacrumbBar control to) being high on my list.
NetBeans has had a documentation problem that has been addressed recently to a good extent; Eclipse has a much more active developer base. But Eclipse is saddled with SWT whose justification of performance: this has always struck me as entirely bogus given that most applications are just menus and standard controls. IBM could have spent the same resources on improving Swing. Recently Eclipse allows you to open a Swing window, which does give a route for a semi-integrated (disintegrated?) port, for example if you have one major Swing-based control. NetBeans allows you to cut out modules from the standard distribution until you get just the sized platform you need; however, once you get rid of the Java-specific modules, the user interface largely disappears, so it is still more work that I would like; on the other hand, NetBeans has nice wizards available for creating some basic RCP configurations.
One option I didn’t look at was whether a Swing applet could run in a browser page embedded in Eclipse. It is a technical option, but klunky. I would say the decision tree for OS-neutral desktop applications now would be something like:
1. Can we implement this using browsers?
2. Should we implement this using Java or Mozilla RCP?
3. (If Java) Eclipse RCP or NetBeans RCP?
IBMs AJAX Toolkit Framework embeds gscko in Eclipse using xulrunner/javaxpcom.
http://www.alphaworks.ibm.com/tech/ajaxtk
http://developer.mozilla.org/en/docs/JavaXPCOM
I'd like to see some effort in building an Office Suite into the RCPs of either Eclipse or Netbeans. Why couldn't the existing editors be enhanced to act as a WYSIWYG word processor? This would be an office suite that would actually be portable and could be extended by enterprise developers in ways that MS Office can not.
Another aspect of this is that Office is in the process of abandoning menu-based user interfaces in favour of their Command Bar (Ribbon) GUI. Flamingo (Swing, in Substance) mentioned above has this kind of control, but there is no equivalent in Eclipse that I know. Indeed, the API of NetBeans and JSR 198 seems to be really based on having a menu bar and a button bar...I am not sure if Eclipse builds this in the same way.
But I don't know why anyone would start a new application without seriously considering having a Command Bar (Ribbon) interface. I made a prototype for Topologi Markup Editor and it really helped things. This is my big caveat for RPCs at the moment: they give you so much but they seem to lock you into a GUI that was state-of-the-art for 2001 not for 2006.
As far as the plugin market goes, MyEclipse just integrated Sun's Matisse into their platform. Matisse4MyEclipse is available in M1 now for free trial. This greatly improves the RCP functionality within the Eclipse/MyEclipse environment.
Matisse4MyEclipse Swing UI designer.
Swing developers feel the pinch too: see Evan Summer's impassioned rave. On the other hand, I think Evan's framework has to compete both against XML-transforming systems and against the other frameworks which have suite power.