Edvin has posted 8 posts at DZone. View Full User Profile

Why I Moved from Eclipse RCP to the NetBeans Platform

07.23.2010
| 43152 views |
  • submit to reddit

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!

Published at DZone with permission of its author, Edvin Syse.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Charles (Ted) Wise replied on Fri, 2010/07/23 - 7:31am

Swing is no cross-platform walk in the park either. And you'll find people advocating leaving Swing for SWT because the Mac platform look-and-feel is substandard on Swing. Take IntelliJ as an example. It looks like the red-headed step child on the Mac. And that's with them going the extra look-and-feel mile. The JetBrains RubyMine product has extra Mac-specific look-and-feel work because Ruby guys are far less forgiving then the Java ones. I'm not saying SWT would have made that work unnecessary, I'm saying it's no different on the Swing side.

The Java write-once run-everywhere mantra isn't true when you're writing a GUI application. Windows and Linux are close enough (or maybe the users just aren't that picky) that you can slide by with only a few platform-specific differences. OS/X is a whole different kettle of fish. Java apps stand out on OS/X like a shining beacon of ugliness. The only exceptions are apps that essentially have different appearances on OS/X then on every other platform.

Choose whichever approach you like but don't expect any panacea in Swing.

Edvin Syse replied on Fri, 2010/07/23 - 9:39am in response to: Charles (Ted) Wise

Hi Charles,

thanks for your comment. I'm very glad you mention this. We use the cross platform look and feel as default in the new version of our app. I don't care (or understand why people think it matters) that the app does not look native - actually I prefer it to look the same on all platforms before having it look native. People often use Windows at work and Mac at home, now they only have to deal with one look of the app.

I've seen your argument many times, but I haven't heard one single end user complain about the look not being native, in fact most users we asked thinks the Metal version looks better than the SWT version. Besides, people can actually change LAF if they want as well :)

As for IDEA, I think it looks good on the Mac, maybe especially because it doesn't look native - it just looks.. well, efficient! Try working with it for a while, and you wont care about the bling, you'll care about the functionality that you can't get anywhere else.

Jaideep Baphna replied on Fri, 2010/07/23 - 10:22am

I agree with Edvin about (a) build scaffolding issues and (b) collections and generics. But the argumentation about cross-platform GUI issues is flawed (see note by another reader at bottom), also the "Hard to extend existing functionality" point ignores power of extension-points, adapters, plug-in, features, fragments, and capabilities, but speaks only about some inheritance constraint, without pointers to how NetBeans improves it. The documentation point is debatable; especially because Edvin is ignoring the depth of the platform plus he ignores help files, Eclipse articles, excellent IBM sites, and Ecosystem books (BIRT, EMF...). His point that OSGi is complex is funny because he goes on to say NetBeans has gone to OSGi too. Now how does a developer reconcile between two module systems in NetBeans? I am not sure how we (Eclipse RCP platform users) can better position ourselves based on this surface analysis. I don't doubt NetBeans is a viable alternative platform to deliver applications, but we need a strong statement of commitment to NetBeans from Oracle, they are too hedged currently. Are they porting all their apps to NetBeans? Have they ceased funding JDeveloper? IBM and most contributors to Eclipse were very clear when they killed all thier internal competing platforms and ported all apps to Eclipse RCP. I think NetBeans is in a state of flux and we need to wait an watch Oracle's moves.

Geertjan Wielenga replied on Fri, 2010/07/23 - 10:32am

No need to wait, Jaideep. Oracle has already made a strong statement of commitment to the NetBeans Platform. Ted Farrell, Chief Architect and Senior Vice President of Oracle: "The NetBeans Platform is very important to a lot of our customers, who are actually building their products on top of the NetBeans Platform. We want to make that the best platform that we can for doing that for you." That's a direct quote from one of the video statements made right after Sun's takeover by Oracle was announced.

And to your question, "Now how does a developer reconcile between two module systems in NetBeans?" The answer is: choose whichever one you like. For your build system, choose Ant or choose Maven, up to you. For module system, choose OSGi or NetBeans module system, your choice. You can even combine OSGi with NetBeans Platform, as the NetBeans Platform EMF integration Tutorial shows.

Finally, your point "the documentation point is debatable; especially because Edvin is ignoring the depth of the platform". Well, you'll find that the NetBeans Platform is pretty deep too. :-) 

Fabrizio Giudici replied on Fri, 2010/07/23 - 11:31am

I'll add that plaing Swing is not good on Mac OS X, but things vastly improve when you use the Quaqua L&F (which is a L&F for Swing, not SWT). You even get "modal sheets" (or what Apple calls them) and the proper file picker of Mac OS X. It requires some work of course, but it can be done. So, saying that Swing WORA doesn't work is false - it just requires, unfortunately, much work than you expected from the WORA promise.

Furthermore, there are lots of third party libraries on Swing, starting from SwingX just to make an example, that make customers happy because they feel they have a reasonably complete set of widgets to use. 

Frankly I completely understand Edvin's point of view, since it's what I experienced in 2005, when first I convinced myself to rewrite a Swing application to Eclipse RCP, started studying it and later gave up because I didn't see what I wanted. Things worked fine with NetBeans RCP and of course I had to work less since I didn't have to abandon Swing. Note that at the time I wasn't such a strong supporter of NetBeans; I'd been using Eclipse since 2001 (probably), in the past I even refused to use the NetBeans IDE for some Sun projects I led (because, in addition to my own preference about the Eclipse IDE at the time, even my developers voted for the Eclipse IDE), thus there was no prejudice. 

Furthermore, when I switched to Mac OS X and passed through the migration of the continous change of native facilities of Apple about graphics (Carbon, Cocoa,...), I got pretty frustrated about the constant problems that Eclipse had with it because of SWT (sometime I still need to use Eclipse if a customer asks me). I had almost zero problems with Swing. While SWT could have been good in the old times, I see it now only as a source of problems and no relevant advantages. 

At last, I find it very good that I can choose the NBM module system or the OSGi module system. The former is pretty good for me and I use it when I don't have any specific requirement. I should add that the fact that it works well is demonstrated by the facility of upgrading and installing plugins in the NetBeans IDE. On the contrary, plugins with Eclipse have been always another source of trouble - and I keep on hearing people complaining about broken Eclipse plugin every time, at work and at the JUG, even by people who still prefer the Eclipse IDE to the NetBeans IDE. Thus, for me there are no doubts that the NetBeans RCP wins on Eclipse RCP.

Jaroslav Tulach replied on Sat, 2010/07/24 - 11:58am

My god, this is awesome article! Of course it is heavily biased towards NetBeans Platform (and I am thankful for that), but the real world observations are just excellent! Just to quote few:
  • "Webstarting SWT has also proven to be problematic" - indeed, that is what we always thought, but this is the proof.
  • "SWT hints & We are programming in Java for a reason!" - who could formulate that better! Indeed I understand the need for conditional extensibility (via hints or other means), but one needs to understand the trade-offs. Swing's trade off are almost none.
  • "No generics" - yes, it took us a lot of work to modify our APIs to be generics ready. It is perfect to know this pays off.
  • "OSGi" - it is fine to have de-facto standard that you can reuse, but for sure, when building your own application there are better alternatives.
  • "Documentation" - thanks Geertjan for doing so great work on documenting NetBeans Platform!
  • "Maven" - Adjusting to standards has always been the biggest NetBeans strength. I wanted to get Eclipse sources recently and yes, it is a nightmare. Is the project still using CVS? Welcome to the stone age!
Dear NetBeans Marketing and Geertjan-like enthusiasts, please record the observations of this article and somehow help everyone who ever wants to write a rich client application to find them! There are just two things I'd like to disagree:
  • "decorators and listeners instead of extending the class directly" - this is quite fair approach in my opinion. Your task as a user of the framework is to submit a patch that adds new decorator. You cannot be angry about that, only if your patch is rejected, you should complain. NetBeans APIs, as I envision them, shall be defensive too and rely on contributions of their users. This is the best way to balance compatibility and extensibility, as far as I can tell.
  • "Conclusions". Another thing to disagree with is your conclusion. After reading this (excellent) practitioner's report, you have no right to say "Eclipse RCP is a good platform". No, it is not. It sucks for all the reasons given in this article. I am sure NetBeans Platform sucks too, but show me such precise description (like yours) why, and I guarantee we'll address the issues in less than one year.
Thanks for your confession!

Edvin Syse replied on Sat, 2010/07/24 - 8:04am

Hi Jaideep,

Let's talk about "Hard to extend existing functionality" and cross platform issues. Let's say I add the SWT.SEARCH hint to a Text component. This works for the Mac, but not anywhere else. Now, how something looks is one thing, but here I actually lose functionality on some platforms. If I try to extend the Text component, I'm greeted with the Eclipse Finger (TM): SWTException: Subclassing not allowed. Yet you bash NetBeans/SWING for LAF inconsistency problems.. That's funny :)

Let's also talk about extension points. First of all, not everything has extension points, for example SWT components do not. Also, both creating extension points and implementing them is just ridiculously verbose, to the point where you actually need Eclipse IDE to make/edit them, and even the GUI editor for them is crappy. On the NetBeans platform there is virtually no boilerplate code needed to write or consume extension points, which actually makes me use them more often now.

Jaroslav, I don't mean that decorators are evil - in fact, they are probably the best way to support extension of existing functionality. I really like that Eclipse RCP use this feature a lot. The problem arises when the decorator interface can't do what you want, and you are not allowed to extend the component that uses the decorator.

Eclipse RCP has lots of good features, but somehow they got lost in a sea of complexity (or what Jaideep likes to call the depth of the platform :)

Antonio Vieiro replied on Sat, 2010/07/24 - 3:04pm in response to: Edvin Syse

Ah, complexity. As Edsger Dijkstra once said: "Simplicity is prerequisite for reliability."

Roger Powell replied on Tue, 2010/07/27 - 12:22pm

Nice article. If all I cared about was RCP, thin client and scripting languages I'd certainly agree with you. Netbeans is clean, clear and great to use. But it's a shadow of its former self ( 6.5 -- 6.7 were the best versions) NB has lost all the SOA, BPEL editor, UML, some XML Schema functionality, the neat web services buildier and goodness knows what else. Oracle support? Don't make me laugh! They surely see Netbeans as a light-weight app builder. All the enterprise stuff was, I guess, too much to give away for free. I'd love to believe it's all on hold pending OSGi implementation. At my university we'll probably ditch NB in favour of Eclipse or possibly wind back the clock and use 6.7 or even 6.5.1

Geertjan Wielenga replied on Tue, 2010/07/27 - 2:00pm in response to: Roger Powell

FYI, the article has nothing at all to do with NetBeans IDE. In fact, the author of the article uses IntelliJ.

Ian Bull replied on Tue, 2010/07/27 - 4:17pm

I'm happy you found a platform that works for you. After all, choosing the right tool for the job is often a difficult task.

However, I wonder how large / complex your application is? The fact that you could simple "re-write it" indicates to me that it's a fairly simplistic tool. The true power of Eclipse RCP comes when you start to scale your application up. When you need to consider things like 'Alternate Execution Environments' or 'Provisioning and SelfUpdate'. If you support 3rd party add-ons (Plugins, extensions, etc...), then the Eclipse extension model and OSGi become indispensable.

To say that the flexibility (you call it complexity) of Eclipse was too much for you application is perfectly reasonable. But you should keep in mind that many of the pain-points you discussed were designed for a reason (and it wasn't to cause you problems ;) ). In my opinion, it would be more interesting to look at these pain-points and then look at how other platforms address them. From here, we could draw real conclusions about the affordances offered by each platform.

Edvin Syse replied on Thu, 2010/07/29 - 4:22pm

Hi Ian,

Our application is very large, it will take us at least a year to port it all, but because of the flexibility in our remoting layer (BRAP), we can continue to let the two versions coexist indefinitely. We have about 10 modules that address specific problem domains like CRM, CMS, booking, calendaring, queue handling etc, and a lot of modules written on a per customer basis. Some of these will probably "never" be ported.

Depending on which customer logs in, modules are downloaded, uninstalled and installed on the fly, and we use quite a bit of the advanced provisioning support in Eclipse.

As most Eclipse advocates, you seem to think that it is ok to be complex just to be flexible. Comparing stuff like extension points in Eclipse and NetBeans, you will see that you get the same amount of flexibility without the complexity.

Also, you seem to imply that if your application isn't huge, no benefit can be drawn from Eclipse, if you take into consideration the extra work and boilerplate that comes with it. NetBeans is a good platform also for smaller applications.

Geertjan Wielenga replied on Wed, 2010/07/28 - 6:49am in response to: Ian Bull

If you support 3rd party add-ons (Plugins, extensions, etc...), then the Eclipse extension model and OSGi become indispensable.

Lots of organizations (military, banking, etc, etc, etc) have created very large scalable pluggable rich-client applications, without ever having needed to touch OSGi, since they use the NetBeans module system which provides very similar features (read the text above, where the author suggests it is even preferable to OSGi in some ways). But, now, if someone does find OSGi to be indispensable, they can use it too, in the NetBeans Platform, without every touching Eclipse RCP or Eclipse IDE. Not saying that that is the ideal solution for everyone (especially if you're using SWT), but to argue that OSGi is indispensable in rich-client applications is clearly false.

Ian Bull replied on Wed, 2010/07/28 - 12:01pm

Edvin, Geertjan, thanks for taking the time to respond.

I'm making two basic assumptions here:
1. Both Eclipse and Netbeans have smart people working on the platform, and they are making intelligent decisions when designing things.
2. Software engineering is about trade-offs. If anybody claims that their solutions are always better, stronger, faster, more flexible, easier to use, etc... I simply discount them. While there are situations where people have made poor decisions, if someone claims that they always do it correctly and other guy is always wrong, then they have been sniffing their own glue for too long.
Assuming we can agree that smart people are working on both platforms and software engineering is about trade-offs then we can have a very meaningful conversation (if we can't agree on that, then you can stop reading now because this will be a very short conversations).
Now I'm not saying that Eclipse RCP doesn't work for small applications, I'm just pointing out that there may be requirements in your software that don't align with the design decisions that Eclipse has taken. Instead of saying that "I don't use platform X because A, B and C are too complicated", I would rather look at why they were designed that way, what the alternative is, and what the different mechanisms enable.
I don't view an Eclipse vs. Netbeans war. Both platforms approach similar problems in different ways, and I think it would help both communities if we brought these platforms closer together.
Anyways, just my $0.02.

Geertjan Wielenga replied on Wed, 2010/07/28 - 12:55pm in response to: Ian Bull

You're unlikely to find either Edvin or myself disagreeing with you. When was the word "always" used, anywhere? In fact, I would very highly recommend Eclipse RCP for those wanting to create SWT-based applications. And it would indeed help to bring Eclipse and NetBeans closer together, but that's already happened very strongly recently, via the new possibility of creating OSGi-based NetBeans Platform applications and of importing existing OSGi bundles into NetBeans Platform applications.

Edvin Syse replied on Thu, 2010/07/29 - 4:23pm

Hi Ian,

I totally agree - smart people are working on both platforms. The Eclipse version has served me well, and Eclipse is a powerful platform. There are tradeoffs to any design decision. I know from experience that any software product tends to develop a kind of best practice or a common path to take when designing new APIs. This is good, especially since a developer will feel comfortable using new APIs right away, because they feel familiar. Patterns are used in similar manner etc.

I do feel however, that the Eclipse APIs tends to be more complicated and require more boilerplate code than similar NetBeans APIs. I have pointed to quite a few in my article. Don't get me wrong, I don't hate complicated stuff, I just feel that Eclipse APIs tends to lack gracefulness. The NetBeans team have gone the extra mile to refine their APIs, like adding generics support and using Collections instead of arrays. This kind of stuff matters a lot in everyday work with the platform.

Prakan Puvibunsuk replied on Fri, 2010/07/30 - 5:20am

NetBeans is the best Java IDE in my point of view.

Hopefully NetBeans will not just give us the wrong direction like Visual JSF and Swing Application Framework,

I spend a lot of time studying VWP and SAF but NetBeans just simply leave me in the dark.

Gilberto Olimpio replied on Sat, 2010/08/21 - 7:02am

Thanks for the good article. I agree that having "less complicated" APIs which results in less + clean code is great and it's a big advantage of NetBeans platform.

@Prakan I don't think such thing as best Java IDE exists. If you ask me, Eclipse is the best one, the refactoring in Eclipse is lot better than Netbeans. If you ask my co-work, IntelliJ Idea is the best one (and I believe him)...the best one is the one you are used to, it'll be the most productive (and yes, I've tried the last Netbeans).

I use to write Java apps for multiple platforms (Mac + Win + Linux) and it's always a pleasant experience, except for the UI. Writing UI in java is a pain...and have the same crap and ugly Metal look and feel for all platforms don't seem to be the solution. People care about the look and feel, people like to experiment different themes in Linux, people like the way OSX looks, and believe it or not, there are people who even like the way Windows looks :) ... So what's the point in delivering something like the outdated java L&F, if most of the people don't like the way it looks? Sun never understood this and I don't believe Oracle will.

I think a good example here is trying to open the file dialog in a Java app (Swing)...it's a crap...ugly...and has fewer features than the native OS file dialog. If the OS already give the file dialog why reinvent the wheel? (I'm not against reinvent the wheel, since we come up with a more efficient one, but in this case, Java came up with a "square" wheel :) )

Sometime ago I had a chance to rewrite a small swing UI app in QT, and what a pleasant experience: faster to develop, it ran a lot faster, but the best of all was the users feedback, 2 things they care most: speed + look&feel (because not is perfect, it didn't look so good with some Gnome themes - although the last QT looks a lot better in Gnome now).

I know, that's about Java, not C++, but QT is a good example that is possible to develop a framework easy to use and that looks great in multiple platforms.

Cata Nic replied on Mon, 2013/09/02 - 4:02am

So far everything works fine. The comments was very helpful and help me to solve the entire problem.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.