Adam Bien's Weblog
Eclipse RCP vs. Netbeans RCP - and what really counts
I'm back from Netbeans World Tour from Poland so I'm totally unbiased :-). During the tour we discussed Eclipse RCP vs. Netbeans RCP again. Actually all of the comparisons I know right now are feature by feature comparisons, which are not very interesting for a real world project. Who cares about a slightly better help, or a different configuration of the menu system?. Both platforms are very comparable; Netbeans relies heavily on the ServiceLoader, which is part of JDK 1.6 and Eclipse RCP uses OSGI which is JSR-291 and will become indirectly a standard (via JSR-277). I read several comparisons, attended at JavaONE 2008 sessions, and all comparisons were so far somehow theoretic if not esoteric.
Because both platform have similar feature set and are both really mature (Netbeans RCP is older, whereby Eclipse RCP is more popular), a feature matrix is no more that interesting for choosing the right platform.
The key difference between both is the UI-Framework. Eclipse RCP is based on native SWT / JFace framework, whereby Netbeans is based on Swing. SWT started as an IDE-toolkit, and Swing was designed as application toolkit from the beginning. Swing isn't native, so that you can extend it, change its behavior in unlimited ways. SWT is more limited - some even trivial tasks can become interesting (in one project we spent an amazing amount of time to provide a vertical lable for a caption of a table). In the role of an architect I would always prefer Swing for UI development, because actually there are no limits. Swing is mature - actually too mature, it hadn't change for several years :-). I prefer Swing programming model too - but this is my personal opinion, in both camps developers can become slightly religious about this topic.
In my opinion SWT / JFace is rather a limitation, than an advantage for a business project. From strategic point of view Eclipse RCP could be more interesting because of countless already existing plugins and extensions. This makes Eclipse especially interesting for development / extension of already existing platforms like SAP, IBM etc. OSGI is hyped at the moment - this should be considered choosing between both of the platforms as well. On the other hand, Netbeans RCP is perfect for the migration of already existing Swing applications - which are countless as well. Since JDK 1.6 u7 and u10 Netbeans RCP has a huge advantage- it already exists on every JDK installation - as VisualVM. ...It is a Netbeans RCP application...
Posted at 12:32PM Nov 05, 2008 by Adam Bien in Netbeans | Kommentare[11]
[my tweets] 
Rss My book: Real World Java EE - Rethinking Best Practices
Very well observed, Adam! The big issue with Eclipse is that Eclipse based applications always look like Eclipse based applications.
That might be desirable in some situations, but it for sure not always is.
Gesendet von Jörg Plewe am November 05, 2008 at 01:08 PM CET #
Hi Adam,
You write: Netbeans RCP is perfect for the migration of already existing Swing applications.
We are currently think of a RCP platform for our existing application. Do you have an idea which are the time-consuming tasks of a migration? And what are the problems that you had with your migration projects?
Thanks a lot.
Greetings from Switzerland
Simion
Gesendet von Simon Martinelli am November 05, 2008 at 02:27 PM CET #
@Simon:
It depends ;-) - for large projects the main migration issue is not a Swing / NetBeans problem. The main work is to change plain JARs (with more or less complex references) to the very hierarchical module system. Here is a small interview about my project: http://netbeans.dzone.com/news/interview-porting-a-crm-applic
best regards,
josh.
Gesendet von Aljoscha Rittner am November 05, 2008 at 03:00 PM CET #
One correction about OSGi: it already is a standard, both through JSR 291 (a fully approved JSR) and through the OSGi Alliance, an industry-wide standards body. In contrast JSR 277 is only at the early draft stage (after 2-3 years) and has little support amongst JCP members.
@Joerg: No, Eclipse RCP applications need not look like Eclipse, just as NetBeans RCP applications need not look like NetBeans. Both sides of the debate should really put this tired old falsehood out of its misery.
Gesendet von Neil Bartlett am November 05, 2008 at 05:24 PM CET #
Having developed tools in both Eclipse and NetBeans the point you bring up is a mixed bag; not quite so pitched toward NetBeans. SWT has some really nice design features: (1) it throws an exception if the event-dispatch-tread rules are not followed; (2) It has better basic controls, e.g., a real tree-table implementation. You can't "skin" Eclipse which several folks above noted.
The capability I really missed in NetBeans is jobs with progress. Eclipse has a really nice jobs framework with a progress monitor. In NetBeans all module developers are stuck rigging up a thread pool with a ProgressHandle.
NetBeans handles updates a lot better than Eclipse. This has always been an awful part of Eclipse and the 3.4 release just made it worse.
Gesendet von Tim Halloran am November 05, 2008 at 10:03 PM CET #
I like Eclipse's way of evolving. They try to stay compatible, but if it is in the interest of the platform and the clients, they break it (from 2.x to 3 for example). The step from 3 to 4 will also break the API, but they will support 3 for some time and _try_ to stay compatible.
NetBeans on the other hand never breaks the API (like the Java way, Tulach is a defender of this strategy). I know staying compatible saves time and money, which is crucial. However, considering money loss or extra time because of old baggage, makes this argument relative.
My opinion in a short way: I prefer Eclipse because it has a more future oriented approach, Netbeans has accomplished much (6.5 will be a good release), but I have the feeling that the whole baggage will limit or slow down it in the future.
my 2 cents
Gesendet von Jim Hanson am November 06, 2008 at 09:56 AM CET #
Swing seems to become some kind of ugly stepchild of grandmother Sun...
Sun setting down on the core Swing:
http://www.pushing-pixels.org/?p=758
Certification to become braindead:
http://blog.jonasbandi.net/2008/09/certification-to-become-braindead.html
Gesendet von Jonas Bandi am November 06, 2008 at 12:36 PM CET #
Hi,
what about Spring RCP? Do you use it? Have any experience? I yes, could you write something?
thanks
Leszek
Gesendet von Leszek Gruchała am November 06, 2008 at 09:20 PM CET #
@Simon:
It depends on how much of the NetBeans APIs/SPIs and architectural principles you want to integrate. The very basic level of adopting the Windows System is easy.
Modularization of third party libraries isn't very hard for small projects but it can lead to challenging classloader problems depending on the libraries in use ( especially reflection and custom classloading can cause problems ). Those problems are hard to understand in the beginning and good information about this part is scarce.
Using the features that NetBeans APIs supply to provide a consistent looking user interface like progress monitors, wizards, etc. would be a possible next step. Not much work involved here.
If you want to adopt the architectural principles in favor of loose coupling that NetBeans RCP promotes beyond ServiceLoader ( e.g. lookups and system filesystem, global selection ), you will want to refactor your application to minimize dependencies and modularize the structure. This might cause a lot of work depending on the code you start with. This is maybe the part where the most work has to be done. On the other hand from my experience this is the part where you gain most, because you end up with better structured and more maintainable code.
If you still want to go further you can refactor you gui components to use the nodes and presenter apis, which involves some work as well. Many projects I've seen skip this step.
Creating functional tests and integrating them with build systems has been difficult, but isn't any more with NetBEans 6.5.
It's up to you, how deeply you want to integrate your project, and how many of the features you want to use. I usually advise my customers to treat the migration as a step-by-step process in order to keep the intervals between shippable versions as small as possible. This way you've got the best control over the process.
Gesendet von Anton Epple am November 09, 2008 at 04:13 PM CET #
@Simon: Depends on depth of integration with NetBeans APIs/SPIs and architectural principles you want. 1. step, adopting the Windows System is easy.
2nd step, modularization of libraries can cause problems that are hard to understand and documentation is scarce.
Using the features that NetBeans APIs supply to provide a consistent looking user interface like progress monitors, wizards, etc. would be a possible next step - not much work.
Adopting the architectural principles for loose coupling beyond ServiceLoader ( lookups and system filesystem, ...), involves refactoring your application to minimize dependencies. This is probably the most work, but it will give you better structured and more maintainable code.
You can adopt the nodes and presenter apis for the gui, though many projects skip this step.
I usually advise customers to migrate in a step-by-step fashion in order to keep the intervals between shippable versions as small as possible.
Gesendet von Anton Epple am November 09, 2008 at 04:27 PM CET #
The only thing that gets me about Netbeans is the plugin architecture. It was not flexible enough (without jumping through hoops and then even then ...) which sadly out-weighed all the other advantages.
Gesendet von Mark am November 10, 2008 at 06:06 PM CET #