Eclipse RCP vs. NetBeans Platform: A Developer's Insights
By Geertjan-Oracle on Sep 13, 2006
I met Kai in Munich, where he is based, at the Siemens conference I went to a few months ago (described here). Recently he ported an MP3 manager/player based on the Eclipse Platform to the NetBeans Platform.
This is his original application, built on the Eclipse Platform:
...and this is the result after porting it to the NetBeans Platform:
In the process of porting his application, he learnt a lot about the NetBeans Platform and, with his extensive Eclipse Platform experience, he shares his perspectives and insights below.
Kai: First of all, here at Siemens we are not religious about our choice of Java rich client platforms. We want to know everything important about all the available technologies. So we want to be able to look at the several different platforms out there and choose the platform that matches our Siemens development requirements. We have different business units and, depending on their needs, they might find one platform more useful than another. Personally, I have a very rich Eclipse RCP background. With that starting point, I started looking at other platforms. For example, I've also looked at the Spring Rich Client Platform, which is at an early stage currently, but looks promising. Next I looked at the NetBeans Platform.
Me: And then what happened...
Kai: Well, the first thing was that I had to install the NetBeans IDE and work with it. Coming from an Eclipse IDE background, using NetBeans IDE was quite painful and still is. :-) But with regards to the platforms, I found Tomohiro Iizuka's article comparing NetBeans to Eclipse (here) very useful.
Me: And how did you progress with the NetBeans Platform?
Kai: Well, overall I had a very positive experience with the NetBeans Platform. When you're at a level where you've mastered the main challenges (for example: lookups, nodes, file systems, branding, update centers), once you've mastered all of that, and you know what you're doing, then it is not too complicated. For me, it was a bit hard to get started, because the tutorials available at that time were pretty basic—I started with the Paint application, then the FeedReader, which both gave me a glimpse of what I needed to know. But when I started with my own application, after just 15 minutes I had issues that were not available in tutorials; issues relating to nodes, selection and so on. But, the more use cases I implemented, the more understanding about the platform’s software architecture I got. However, often I ran into specific details, how to do some specific things. For example: "What is the best way to leverage a specific aspect of the NetBeans Platform rather than re-inventing the wheel."
Me: How did you solve these questions you had?
Kai: There are some very good resources. For one thing, the mailing list (click here) is very good. However, it is too unstructured. Even though I can search for keywords, I often got a very long unstructured list, from 2001 to 2006, totally mixed! So then I had to browse through all these topics. I would have maybe 50 matches, while 2 would turn out to be useful. But, besides that, it is a good resource.
Me: Now that you've ported your application, what would you say is your level of understanding of the NetBeans Platform?
Kai: Right now, I wouldn't consider myself an expert and I know way more about Eclipse RCP. However, I am at the stage where I could definitely start a domain-specific application and be able to focus on domain-specific things, because I am able to use the NetBeans Platform to leverage the boilerplate underlying infrastructural code. The result of such a domain-specific application that I can now build on the NetBeans Platform is decent, looks professional and has good usability. Basically, I could ship such an application within Siemens, and it would be a completely acceptable RCP application.
Me: Excellent. Aside from the difficulties you had getting started with NetBeans IDE, are there things you have come to like about it?
Kai: Well, as I mentioned, the NetBeans IDE is not my favorite IDE, but there are definitely some things that I like. What I like a lot are the wizards in the module development area. There are many very useful wizards that generate code that you can use directly with very little modification. But, my initial issue with every wizard is that I want to understand what is behind it and what it generates, before using it. For example, with the File Type wizard, you get five or six different files, so I first needed to know what's behind those files in terms of the architecture and know what I would get and how to use it efficiently.
Me: What were some painful moments you experienced while porting your application?
Kai: Very painful using the NetBeans IDE was the turn-around time in the application development cycles. In normal development, I make very small changes and then test them. For example, I might change an icon and then want to test it immediately. When using Eclipse, I make one change in the source code, save and everything compiles in the background automatically in no time. Then I just launch the application and almost immediately see the result. With the NetBeans IDE, I make one change in the source code and when I run the application, many Ant scripts are run—and then only about 45 seconds later my application is started up. I do this so many times a day that I would save 30 minutes to an hour in my normal programming with the Eclipse IDE, because there I don't have to wait after every little change to be visible. (Update: See this blog entry to turn your module development turnaround time from 45 seconds to 3 seconds.)
In fact, one of my interns is now trying to build a launcher for NetBeans applications in Eclipse IDE, and is making good progress. In NetBeans, since I like the module development wizards and lots of its good tools, I would like to use the NetBeans IDE wizards for initial setup, and for populating layer.xml files and so on, but when it comes to coding, I would like to continue to use Eclipse IDE, where I can just click run and debug and everything more quickly. Therefore, from my point of view, it would be a big improvement for the NetBeans IDE if the development cycles could be reduced.
Me: Looking at your application, I see nodes, a TopComponent, a TreeTableView... so you must have used quite a few of the NetBeans APIs. Can you share your experiences with them?
Kai: I really like the resource management with nodes and data objects. It is a pretty general thing that can be used in domain-specific applications pretty well. But it is, of course, a little bit hard to get started with all the nodes stuff. When you come from the Eclipse Platform, you know about resources, adapters, content & label providers and so on, and there isn't a concept similar to NetBeans nodes for encapsulation of API objects. But, when I got used to it, I found it quite useful.
I had a hard time understanding the selection mechanisms and how they work together with activated TopComponents (like the ID3 Editor). I had to create a node in my editor just for enabling actions—I created a SaveCookie in the editor, based on the state of my API object. On the other hand, I like the file and loader stuff. It is nice that it is possible to declare external actions from the outside that are bound at runtime to a given file. So now I could define the Play action in an external module and bind it to the MP3 file declaratively. What I also like is that I can use my own MIME types and folder types. It’s a nice feature being able to bind actions to every folder via "any" in the layer.xml file.
With regards to the Nodes API, in the beginning I had a few problems with leaf nodes and Children.Keys, which are different objects, and where to initialize them.
What I like is that I can separate initialization of a model from visualization via, for example, the BeanTreeView. The nodes are lazily loaded and created when expanded, but I could initialize the underlying data model eagerly if I wanted. The Explorer Manager API is nice because of its concept of an explorer manager being loosely coupled from views. These are easy to use once you have mastered the Nodes API. Another nice thing is that table columns are created by properties of nodes. However, I want to use the TreeTableView as a view and not as editor. So, the small buttons for editing are superfluous to my needs and get in the way. I would like to know how to remove them. What I also like, is that the first column gets its own scroll bar, but why aren’t the column widths made persistent by default? Of course, these are minor things, but I'd like to know the answers! But it is really great to have a component such as the TreeTableView in the NetBeans Platform.
Me: Other comments on the NetBeans Platform?
Kai: For me, branding is very important for two scenarios: Firstly, for product line development, secondly, to be able to deploy the same software base for different customers with customer specific branding. What I really like is how easy it is to define a splash screen, progress bar, and a line of text for the splash screen, in the module suite. It is nice that you can preview your splash screen with text and progress bar in the IDE. In this particular case, the NetBeans IDE is even a bit better than the Eclipse IDE! So, one of my interns implemented a plug-in for Eclipse based on the NetBeans splash screen preview functionality! In fact, that was the first time I thought that NetBeans IDE provided a feature that I would really love to see in the Eclipse IDE. Probably I will make our plug-in for splash screen preview open source soon.
However, compared with Eclipse RCP branding, in NetBeans the branding support is too basic. In NetBeans you can brand a splash screen and icon, but what’s missing is the launcher icon (issue 64612). The About dialog box isn't really possible to brand. The splash screen is copied and a bunch of system properties, but it would be great to put other branding information there, such as a smaller image, localized text which is branding specific, for specific customers. For example, for a customer-specific branding, end users would expect to read something specific about the customer in their branded application's About dialog box. Currently, I would have to create a whole new About dialog box, instead of adding some specific information to the existing one. In the Eclipse RCP there is good support for that. In fact, you can brand each feature and plug-in separately, in addition to the application product branding. When you create a domain-specific RCP application that is extensible, and third parties can provide their own plug-ins, the long/short descriptions in NetBeans are probably not enough, I would like visible clues (such as icons per module) to identify what third parties have provided.
Aside from the branding support, what I also like is the ease of integration of the JavaHelp help system. However, there are some issues with details—to provide internationalized help systems, and you have to do some hacks when you want to use application specific start ups for help. And I don't know how to change the title "IDE Help" to something different! But, in general, the binding of the help system to the application is pretty easy. JavaHelp is a little bit out dated, but is still okay.
Eclipse provides also very good help support. It is very easy to integrate the help system of the Eclipse IDE, which uses Tomcat as the web server and Lucene as its indexing engine. The good thing with this approach is that you could provide sophisticated stuff, such as JSP pages for dynamically changed context. JavaHelp is purely static, which is totally okay for most use cases, by the way.
I also like the Update Center mechanism. Of course, using it straight from the NetBeans Platform is not the best usability for many domain specific applications. The users might just want to click a button that says "Update" and then the update is done automatically in the background, without the user being required to work through the Update Center wizard. The related API should be useful to create such an approach. Eclipse RCP uses a similar approach; you could reuse the IDEs Update functionality or use the fine grained Update APIs.
Something else I wondered about is Web Start in the context of Update Centers. If third party libraries are installed via an update center in an application started via Web Start, would a new version of the Web Start application not overwrite the modules installed via the Update Center?
It is even possible to deploy Eclipse RCP based application through Web Start. What I would do then is—I would provide only the most basic application via Web Start and then use the platform update mechanism for the rest. I guess this approach would probably work with NetBeans too.
The last thing I investigated was the issue of long running processes and asynchronous tasks that can be canceled through the user interface. For these I used the Progress API, with its progress handles and progress factories, and it worked fine for my use cases.
What I really like in the NetBeans Platform is its docking system! Being able to move the windows around and dock/undock them... nice. Makes my application look pretty mature!
Me: What are some of the remaining concerns that you have?
Kai: Well, with the NetBeans Platform, when you want to do one specific thing, as a beginner it is often hard to find a best practice example. For example, with lookups you have several approaches. There's the general lookup, which is good for simplicity and easy to use and understand and you could use some declarations in the layer.xml files, too.
Similarly, with the layer.xml files—in every module you can see a tree view for the current layer.xml file as well as the entire context, and I like that. On the other hand, I had problems when I wanted to reuse the Tools menu provided by the NetBeans Platform, but I wanted to delete a few menu entries from that menu. But I had also created a module that used those entries that were deleted. So, there were some inconsistencies about that and, once deleted, it was hard to get the entries back. For example, several modules contribute to the application's File menu. So, I screwed up the File menu and then I had to delete everything in it and then build it again from scratch.
Application life cycle handling could also be better. Module installers are nice but very basic. The Eclipse Rich Client Platform has very good application life cycle management. The NetBeans Platform needs hooks such as PreMainWindowOpen, PostMainWindowOpen, and PostMainWindowClosed. In JSR 296, probably there will be an approach for application lifecycle management that the NetBeans Platform could adopt.
Something else—I'm not able to sign all NBM files belonging to a suite with my own keystore. I found two approaches on the web, but neither worked for me. Even when I use the default keystore, I couldn't start Web Start because some of the JAR files were generated corruptly. I am not sure what causes that, but since it worked with a smaller test application there is probably a detail I just don’t know yet.
Me: Can you comment on your perspective on the factors that could determine whether one chooses to use the Eclipse Platform or the NetBeans Platform?
Kai: Well, it often depends on the "legacy" of the users involved. For example, if there is already an existing monolithic RCP application that you want to port to a platform, to get rid of all the underlying mechanisms that a platform provides out of the box, if the application is built on Swing components it would be a pretty big effort to port them to SWT. In contrast, porting such an application to the NetBeans Platform, would make it easier to reuse UI components. If the requirement is that the application is to be built in Swing, then the NetBeans Platform makes the most sense.
If there is no such requirement about which UI toolkit to use, there might be a requirement that the application should look & feel as native as possible. SWT based Eclipse RCP would then be a very good choice, although the native look of Swing is constantly improving and in Java 6 should be even better in terms of native look and feel. In fact, both Swing and SWT are getting better and better and both are really fantastic UI toolkits. I started with Swing 0.2, and still am a Swing fan but I also like SWT, JFace and Workbench very much. :-)
Software engineers are notoriously bad user interface designers with Swing, with a few exceptions :-), but Matisse should make things a lot easier.
If you have a developer community that uses NetBeans already, then it would probably be much easier for them to use the NetBeans Platform, because they are familiar with the concepts already. In terms of documentation, NetBeans is really catching up too.
In summary, right now there are several players in the Rich Client Platform space and the NetBeans Platform is definitely worth considering.
Me: And so, after your whole experience porting your application, what's your personal perspective on the two platforms?
Kai: Well, I already love Eclipse RCP and I like the NetBeans Platform, too. They both give so much functionality, even though it takes a long time to understand everything fully. However, only a few people need to know everything, but there are a couple of core things that are needed to be understood to work with each of the platforms. In these core things, both platforms provide a lot of functionality, and it is worth it to evaluate the application's requirements first and then choose the platform that fits best. Right now, when I get to coach or assist in making platform choices, I would present both, Eclipse RCP and NetBeans Platform, because, as I said before, there are use cases where the NetBeans Platform would be a truly excellent choice.