Categories

Comparing Eclipse and NetBeans RCPs

I recently had the opportunity to see a presentation about NetBeans RCP given by Geertjan Wielenga at AlpesJUG, and to chat with the speaker afterwards. We had an interesting discussion about how NetBeans RCP and Eclipse RCP compare to each other.

Some food for the trolls

DISCLAIMER: Before you start reading this article, I have to tell you that I am an Eclipse fanboy, a contributor on several Eclipse.org projects, developer of an Eclipse RCP app, and have been developing Eclipse plug-ins since I left school. Although I try to be objective in the following article, you may feel it is too Eclipse-oriented. If this is the case, I am sorry…but Eclipse is better ;)

RCP applications are developed exactly the same way with NetBeans or Eclipse

Most of differences between Eclipse RCP and NetBeans RCP development are just in terminology. In NetBeans we speak of modules, in Eclipse, of plugins; we use the NetBeans Platform instead of Equinox, we have Matisse instead of Window Builder. We also have an extension registry with extension points on both platforms, to contribute extensions, and an RCP application is a set of provided modules/plugins + some of your own extensions.

It is the same thing; we can develop them the same way with either Netbeans or Eclipse.

Eclipse RCP vs NetBeans RCP starts with… SWT vs Swing

When getting started with RCP development, here is the main thing encountered, and this is technically the main difference between both Platforms: Netbeans uses Swing as a widget library, whereas Eclipse uses SWT. In my opinion, that’s not a big difference, but when it comes to choosing between Netbeans and Eclipse, there is a bigger impact when you start a new application or migrate a legacy one. People will probably choose the product with their favorite widget API.

This is the main technical difference, but it is really minor. In my opinion, this difference is not important enough to make a distinction.  Let’s look deeper, to see what these solutions provide as extensions and so on.

NetBeans is not an OSGi platform, but…

It provides exactly the same necessary features as what is used when developing Eclipse RCP plugins. MANIFEST has different keywords, but there are still modules (or plugins in Eclipse terminology) with their own classloaders and so on.

Additionally, there are a lot of integrations with OSGi. The NetBeans platform can run along with an OSGi container, and it can handle OSGi Bundles. For RCP development, the NetBeans platform provides all the necessary OSGi stuff RCP developers use. During his presentation, Geertjan highlighted some NetBeans OSGi integration by starting Netbeans over Equinox and loading EMF bundles in NetBeans.

NetBeans has an publisher, Eclipse has an ecosystem

That’s probabably one of the key arguments in the debate, and it has a very strong influence on both products. The entire NetBeans roadmap is piloted by Oracle which is wholly responsible for it. At Eclipse, there is no such single pilot. The Eclipse Fundation oversees Eclipse development, but there is not ONE single publisher, there are lots of contributors from different companies. Eclipse is not only modular technically, it is also modular in term of organization. There are several projects that are developed by independent groups. There might be some dependencies between them, but in the end, you have different teams developing different projects.

NetBeans is a single project developed by a company, whereas Eclipse is an amalgamation of different projects developed by a community of individuals and companies. Then…

NetBeans is homogeneous, Eclipse is heterogeneous

Eclipse developers must admit this: NetBeans is much more homogeneous than Eclipse. And this is true in several domains: UI, ergonomics, code quality (which by the way is quite good, according to NetBeans users who find it less buggy than Eclipse code). This is a plus for NetBeans since users who know how to do one task with NetBeans will easily figure out how to do another. It is pretty user-friendly, especially for users who are new to the Java IDEs world.  They can easily leverage most of the IDE and the platform; thanks to its high consistency (standardization). Thus NetBeans rapidly becomes straightforward to use and leverage.

Compared to NetBeans, Eclipse seems difficult to fully manipulate. There can be a lot of differences between 2 projects, in term of usability (creating a web project is quite different than creating a plug-in project, as you often need to learn how to do something), and also in term of quality. The Eclipse platform quality is very good, and so are most of the mature projects, but there are some others are more buggy and makes the IDE less comfortable. Also, when you reuse some code from other projects, you often have to tweak it to get it working well. For Eclipse developers like me, that’s no big deal; but for new users or for people coming from NetBeans, that can be a major issue.

and…

NetBeans has some tools, Eclipse has a lot of projects

The openness of Eclipse provides something very different from NetBeans. NetBeans is one product with different tools. Eclipse is one platform with different projects. These projects are much more numerous than NetBeans components, and they allow you to take several roads at the same time. Eclipse has a kind of wide usefulness that can handle classic IDE problems, Mobile-Development problems, Model-Driven problems, Rich Internet Application problems, and so on.

Two years ago when it was time to choose a name for the 2010 “Helios” Eclipse release, I especially liked the proposal for Hydra, because it is made of one body and several heads. This is a metaphor that fits Eclipse well. To go further with the Hydra comparison, it is considered to be a monster by many people, though a very powerful one…

Eclipse projects - so many, so powerful

I see in NetBeans something more under control, more cohesive, and less scattered. Great tools are provided with NetBeans (Matisse, Installer Framework, and more) to facilitate the development of RCP apps. Getting started with RCP is probably easier with NetBeans since things are more consistent, but I sense a lack of opportunity to find and reuse some very cool things from other projects – one of the great things you get used to in developing Eclipse RCPs. (I remember how tickled we were to discover and reuse the wiki capabilities of Mylyn.)

If I had to use a mythological metaphor, I think I would compare NetBeans to a Minotaur: a strong and nice-looking beast, but with only a single head ;)

The "simpler" NetBeans: good-looking isn't everything

15 Responses (and one trackback)

  1. #1 by Tom Schindl on June 6th, 2011

    What you say about SWT and Swing is correct for 3.x but the upcoming platform 4.x is widget toolkit agnostic. Don’t believe me? Just take a look at my github-repo (https://github.com/tomsontom/emfdatabinding-tutorial) where I experiment with Swing and JavaFX as a UI-Toolkit to write RCP-Applications using Eclipse 4 Application Platform.

  2. #2 by mickael.istria.eclipse on June 6th, 2011

    @Tom: That would be an amazing move! I’m eager to see an Eclipse IDE running on JavaFX.

  3. #3 by Tom Schindl on June 6th, 2011

    The Eclipse IDE itself will probably never run on JavaFX because all the editors, viewers, … are written for SWT but for RCP Applications where most of your views are written by yourself the situation is totally different.

  4. #4 by Chris Aniszczyk on June 6th, 2011

    Hah, I like the Hydra analogy also.

    You can cut off a head but another one grows ;)

  5. #5 by MilosS on June 6th, 2011

    Thanks for great comparison. One note about my feeling: The Hydra label is well for Eclipse because the both are incomprehensible… :-)

  6. #6 by mickael.istria.eclipse on June 7th, 2011

    @MilosS: Glad you like it. Although I am not totally sure of what you mean by “incomprehensible” (trolls army in progress ;)

  7. #7 by Luís Carlos Moreira da Costa on June 7th, 2011

    Thanks for great comparison.

  8. #8 by Rich on June 7th, 2011

    “This is the main technical difference, but it is really minor. In my opinion, this difference is not important enough to make a distinction.”

    I realize your comparison is between the respective RCP platforms but once you’ve committed to one or the other, you really need to look more generally at Java development for the desktop. In that case, SWT vs. Swing *does make* a big difference. This is especially true if your desktop application needs to run well on Windows, Mac & Linux. If you’re only targeting Windows, you’re better served using Windows tools (Visual C#, C++ or VB). SWT isn’t a serious choice if you must run on those three platforms and SWT is a poor substitute if you’re only targeting Windows.

    That being said, there are some other important considerations. If you need to integrate tightly with the OS or other non-Java applications, Swing can be painful (if that’s not important, Swing is (IMHO) a better option). Also, Sun never really developed much of a widget environment so you don’t have much variety there out of the box. So you end up having to do more work if you want to do fancy stuff.

  9. #9 by Pietro on June 9th, 2011

    Your opinion is fine.

    As you said, the Netbeans interface is more consistent and I like it very much.

    As a complement to Rich words, I worked with Eclipse on Windows and look nice but under Linux becomes really ugly. SWT is a crap.

  10. #10 by mickael.istria.eclipse on June 9th, 2011

    On Linux, SWT generally runs on GTK. Version 2 of GTK now looks old, so that Eclipse can look less beautiful than on Linux (although I don’t see a major difference between both platform for our use cases).
    GTK 3 has been recently released, and more and more distributions use it by default. Then SWT will for sure leverage the benefits of this new version of GTK to look nicer on Windows.

  11. #11 by MilosS on June 14th, 2011

    @mickael: Hi, NetBeans seems me more friendly, go and work. For Eclipse and JDeveloper (Borland) style IDEs you need some tutorial or practice. May be, the my IQ capacity is unsufficient. (Trolls? I have a fire-wall :-) )

  12. #12 by mickael.istria.eclipse on June 14th, 2011

    I agree with NetBeans accessibility better than Eclipse one. However, you are speaking of IDEs, whereas this post focus on RCPs.

  13. #13 by Estiedi on June 20th, 2011

    I used Netbeans and Eclipse as IDE. I found Netbeans easier to use, better integrated with Maven, it had a decent GUI editor (this was before the Google takeover of Instantiations) and probably most important it had consistent builds and no need for a workspace.
    RCP however is a whole other beast: I’ve done both: Eclipse based RCP applications as well as Netbeans RCP applications. I had a lot more trouble with the Netbeans RCP applications. Several times I had to search through tons of APIs and even read the source code to find the functionality I wanted, Eclipse is much easier in that area.
    So, even though I preferred Netbeans over Eclipse as an IDE, I would without a doubt recommend Eclipse for RCP applications.
    Anyway, since Oracle took over Sun, I was too worried about the future of Netbeans and continued with Eclipse.

  14. #14 by Ox on November 22nd, 2011

    NetBeans is more user friendly, easier to manage project’s configuration, work nicer and better, source control is integrated better, i.e. we can see in the moment what is changed…

    Eclipse: Lot of bullshit :D in menus, sucking fucking perspectives wtf !”#$%&/(), it happens that project configuration is suddenly not OK anymore :S (at the moment I am looking for this solution already 3 days)

    BTW many heads??? Why do you want to have several dicks if you can not use them at once?
    Quality (one head) is better then quantity….

    Sorry for my English and everything else…

  15. #15 by Jit on January 14th, 2012

    Netbeans is really user friendly and is great for doing stuff easily… after all we dont want our developers to fumble with the IDE much to get the work done….

    BUT, a big BUT…
    Netbeans suffers from java’s memory issues…. gets really slow after 20-22 hours of continuous run…. although a system reboot solves that… waiting for java8

Comments are closed.