Why I Moved from Eclipse RCP to the NetBeans Platform

The management tool for our Tornado CMS was originally written as a web application and then later ported to Eclipse RCP.

We have been quite satisfied with the functionality of the application, but the development process has not been pleasant. In the following I'll outline my main reasons for switching from Eclipse RCP to the NetBeans Platform.

Portability

Eclipse uses SWT instead of Swing. SWT uses native bindings so that it looks and feels like a native application, and the speed is great. SWT requires a native library for each target platform, but some functionality either isn't available on all platforms, or it behaves differently. In SWT, you configure components by giving them hints, and the platform in question might or might not support the hints given. The end result is that we must do far more debugging on each platform, and I often find a beautifully constructed GUI on the Mac to look like crap on Windows, requiring adjustments like for example treating transparency etc differently. We are programming in Java for a reason!

Webstarting SWT has also proven to be problematic, and I wasted a lot of time getting it right, especially on the Mac because of the -XstartOnFirstThread issue. Google it, and get ready to pull out some hair.

When we write code that does low level drawing the issues are far worse. The window system events sent by each platform seem to differ, so again, a nice custom drawn object looks good on one platform, and requires lots of debugging to get right on other platforms. Debugging standards compliant HTML/CSS to make it work in Internet Explorer comes to mind...

Hard to extend existing functionality

It seems the "Eclipse way" is to add decorators and listeners to classes to extend their functionality, instead of extending the class directly. This is quite nice in theory, but some times you can't get the right hooks, and you end up reimplementing existing functionality just to tweak it slightly. This also wastes my time. Eclipse classes actually check whether you extend them, throwing Runtime Exceptions if you do.

No generics

Eclipse API's mostly don't use generics, so you scatter ugly casts all over your code. Many API's use arrays where they could use the Collections API, again making your code look extinct before you even saved it. NetBeans API's are rich with generics and Collections API usage. Now I feel like I'm programming in Java again!

Eclipse, the IDE

I started programming in Eclipse, but quickly changed to IntelliJ IDEA, and I'm never looking back. Eclipse RCP "forces" you to use Eclipse IDE for a couple of reasons.

There is so much boiler plate configuration that you want to use wizards. (On top of that, when the wizards and forms start bugging on you regularly, you get kind of discouraged).

Getting a headless build is a really painful process (and poorly documented), and even if you get it right, you'll still be going back and forth for wizards, to add dependencies etc.

The first thing I fell in love with on the NetBeans Platform is the Maven support. Out of the box you get a perfectly good headless build system, that even automatically makes wrapper modules for stuff that isn't available as a NetBeans module. Better yet, I can continue to program with IDEA, and the Maven build even gives me Web Start artifacts out of the box. I have literally wasted weeks getting Web Start and headless build to work perfectly for Eclipse, this was all ready for me when I switched to the NetBeans Platform. Oh, and today I upgraded my application from NetBeans 6.8 to 6.9 - it took me five minutes, including the recompile.

OSGi

The Eclipse module system is OSGi based. The theories behind OSGi all makes sense, and the module system does work good, but it is overly complex compared to the NetBeans module system. This is especially evident in the module update process. Getting silent updates working perfectly again wasted many workdays for me. NetBeans also supports OSGi, if that's your bag, but I find the default module system to be much more no-nonsense, and does all I need it to do.

Documentation

I feel like the Eclipse RCP team doesn't take documentation seriously enough. Far too much of my Eclipse RCP knowledge came from trial/error and google searches, instead of from official documentation and javadocs. After reading 500 pages of an Eclipse RCP book I knew less about the platform than I learned about NetBeans Platform just by reading Geertjan's blog and browsing the official documentation. A comparable book on the NetBeans Platform is just over 300 pages, and again - after reading it you get a good understanding of the platform, instead of an overwhelming feeling of unnecessary complexity that I got when reading about Eclipse RCP.

Actually, it was the documentation and all the updated and relevant examples available for the NetBeans Platform that actually made me switch. Now that I have, I don't miss Eclipse RCP one bit, and I'm glad I once again can concentrate on my problem domain, instead of wrestling with the development platform.

Conclusion

All in all, Eclipse RCP is a good platform once you get to know it, but even now that I feel like I understand it ok, I'm still doing more work and dealing with more complexity than I should. I can  understand the need to support a Java version that has been dead for years but I don't need to be punished for that on a daily basis.

I've wasted countless days struggling with stuff that should be working out of the box, and that IS working out of the box with the NetBeans Platform. I'm so happy I made the switch, and my two best buddies IDEA and NBP are getting along like I never even dared hope for!