Rich Client Platforms Compared

Recently I decided to get up to speed on at least one rich client platform for a project we had. Over the years I had come across references to Eclipses RCP and Netbeans RCP so I started with those two. I later picked up a third platform from the springframework called Spring-RichClient. In this blog I summarise my experiences and opinion on each platform below. An expert in any of these platforms will probably take issue with what I say and I acknowledge that this is not an in-depth review but I did investigated each platform and attempt to write my project in each and got quite far down the path in each case before settling on my choice.

Netbeans Rich Client Platform

I decided to use Netbeans RCP first, over Eclispe, because of the compeling argument that it uses swing and I wouldn't have to learn a new widget toolkit like Eclipses SWT. Since time was of the essence, isn't it always, Netbeans was first on the list.

A summary of my experience is that Netbeans is a powerful platform, with a steep learning curve for its APIS, but let down most by its module system. I found this platform hard to get into. Maybe because it was my first RCP platform and I needed to understand the problems that they are trying to solve, like menus and selection events.

The first couple of tutorials on the Netbeans site, I did not find very useful for understanding RCP overall, but they introduced me to the steps one needed to follow to create a RCP Application. One of the issues that struck me from the beginning was the uneasy feeling of being trapped into a specific IDE. The IDE automates a lot of the nitty-gritty stuff relating to the platform and is highly integrated so you can't use another IDE, unless I suppose, you are prepared for a lot of pain. This is pretty much the same with Eclipse.

I like to use a build process that enables the project to be built without an ide, and allows ide independence. So we use maven for the build process and developers are free to pick their poison. To be fair Netbeans does provide an option to create a RCP project using maven. I tried it but it didn't work and since I didn't want to fight with the IDE about maven pom files while learning something new I used the Netbeans Application wizard instead.

After struggling through the tutorials I came across GertJans screencasts. This made progress infinitely easier once I had worked through them. The screencasts provide a context for Netbeans RCP APIs, which the tutorials failed to provide. Although the Netbeans crowd is proud of their APIs I found them a bit counter-intuitive, and that learning was not a simple process of seeing what auto-complete bought up and reading the Java Doc. I found the way Nodes and their children are constructed, for example, a bit difficult to grasp without consulting the java docs for several classes and their methods.

I was also a bit disappointed in the platform's lack of OS integration such as with tray icons, mime registry lookup and file associations which I was kind of hoping the RCP would give me. But having said that their API's are quiet comprehensive. Basically the stuff from JDIC not yet in the JDK.

The most annoying thing about Netbeans in the end was the module system. I sure hope that the introduction of modularisation to Java doesn't make it this difficult or messy. The need to wrap all third party libraries in a module was what killed it for me in the end. Basically I felt like I had disappeared down a rabbit hole and was just getting further and further away from my goal. As any Java developer knows there are hundreds of open source dependencies that any sophisticated library such as JPA will rely on. Trying to track down and wrap these all was a real pain. Maybe I was doing it wrong but then again it should not be so difficult. Still there are reports of some projects with 60 modules! Its not so bad if you think of these like packages but trying to manage 60 projects to get one app going sounds like a nightmare to me. I guess once I figure this out properly it will be ok.

I will definitely be investigating the platform further but need to get the Netbeans RCP book !

Springframwork - RichClient RCP

When I discovered RichClient I thought I had been saved. The framework makes use of maven natively and feels more like the way I develop application than any of the other platforms. Since I use the springframework in web apps, I was also familiar with its application context config files and general spring approach. Its API's also seemed more natural to follow and understand that Netbeans, and I was up to speed, once I found the documentation to read! Of all the three it was the most natural to me. Whereas the other platforms clearly had trouble in trying to generalise their technologies from the IDE problem space, RichClient did not have this problem.

I liked its "plugin" approach to using existing open source frameworks for docking which meant that one could swop out one for another relatively easily. Its the feeling of freedom you get using open-source. The biggest challenge was finding documentation for the framework. I did eventually find a comprehensive PDF, sorry I lost the link. But while ploughing through the RichClient site I was left with the uneasy feeling of a project that was like a step-child to the main project. It was clearly underfunded and not a top-priority for management at spring source.

The health of the project was questioned repeatedly in the forums and strenuously denied by the community leaders, but the decision by management to suddenly release a 1.0 version in March 2008 when the last release, 0.2.1, was done in Sep 2006, with the announcement that a new project was to be undertaken to rewrite the platform, did not fill me with confidence. Beside, it was clear I was learning a dead or dying technology so why persist when I could learn a technology that was going to be around for a lot longer? So sadly I left sping richclient behind.

Eclipse Rich Client Platform

I was eventually left with Eclipse. Luckily for me the 3.4 release seems to be stable now, although its update mechanism seems to be more stuffed than usual! I managed to carefully select the plugin development packages I needed without there being a conflict of some kind. With that out the way I could proceed. This was time consuming as it takes about 20 minutes to work out there is a problem with your selection as it needs to download from repositories to do this.

Since Eclipse RCP has been around the longest I found it had the most documentation and it was easy to find tutorials and articles. I also found its API more intuitive than Netbeans, but this may be due to the increased experience I now had. I thought the SWT widget set would be time consuming to get up to speed on, but one of the benefits of all these platforms is that they have wrapper classes for most controls and provide a lot of basic plumbing, that meant I didn't have to touch to much gui code directly to get what I wanted. The wrapper classes technology is called JFaces in the Eclipse world. As with most enterprise apps they mostly consist of trees, tables and lists which covers about 99% of business apps.

I got the same trapped feeling using Eclipse as I did with Netbeans, but its modular system was easier to get working than netbeans. Note I did not say figured out but just working. I have not had time to look at the technical aspects of either IDE's approach to library modularisation. I was also disappointed with Eclispe's minimalistic integration with the OS, although it was much better than Netbeans. This is one of the core areas a RCP should address in my opinion. It cannot be addressed in the JDK because of the diversity of operating systems, but getting file associations, user home directories and system tray integration is a big problem area for desktop development. Eclipse at least provides great system tray integration!

As with Netbeans, Eclipse is struggling to make its platform more generic and less tied to its IDE roots. It seems to have been more successful at this than Netbeans though having done a major refactoring several releases back.

The biggest issue with Eclipse was with its global objects and terminology. It seems there are a hundred ways to get a references to a view but they don't work in all situations and you are left wondering why. This was the same as getting a reference to the current Display or active site.


I think RCP platforms need more attention. They are great way to speed up development time and provide Java developers with the close operating system integration that is required with Desktop applications. With the move towards the desktop they will become increasingly important and will eventually fulfill the same role as application servers for web apps. This is especially important given the need to handle multi-threading in way that your average developer can easily use. I definitely think there will be a merge between RCP and RIA but this is a subject for my next blog.


"Still there are reports of some projects with 60 modules!"

Actually, my project has more than 200 (I have to count them again, I think). The project itself is split in several, independent subprojects for two reasons: 1) a lot of stuff is reusable in other contexts 2) since I'm not working on everything at the same time, the split brings down the compilation time.

In general, I'm oriented towards projects where modules are highly cohesive - as it happens for classes in OO design, it's better to have many small things, focused on a single task, than fewer large things.

In any case, I understand the pain points you've listed. They have been more or less when I learned the NetBeans Platform three years ago (but at the time there were much less tutorials and screencasts). We will surely work on the problems you've listed to make things easier. BTW, some things can be done today (e.g. you can create and maintain a NetBeans Platform project only relying or Ant - and probably Maven - without need of the IDE), but with an additional pain level (no wizards in Eclipse for NetBeans RCP, of course, and a good deal of manual set up to be done initially).


Fabrizio Giudici
NetBeans Dream Team