NetBeans vs. Eclipse RCP: Plugin Mechanism Comparison

It's an interesting topic and a great starting point. But, at least from the NetBeans perspective, the comparison is a bit incomplete. For example, there's no requirement to register the providers in the layer.xml file. You could, instead, use the official JDK 6 ServiceLoader approach, and register the provider(s) in the META-INF/services folder. That also solves one of your disadvantages, i.e., the one about content being mixed in the layer.xml file: that's purely a question of choice. Personally, I prefer the META-INF/services approach because that way I can more easily identify my providers.

"The extension point does not define itself: there is no information about which module-public interface is used as an extension point."

Perhaps I've not fully understood the point... Why should I know that by defaut? It is a good design principle to separate interfaces from implementations, so the only thing I need to know is that there is an extension point, not necessarily where it comes from.

"The lookup name to be used is also undefined."

The lookup name is the class itself: what better name could I imagine? If I need an extension point (which I prefer to call service) is because I need to do something with it, that is I know that I need its interface / abstact class. Why should I also search for another kind of name?

'The extension and other content are mixed in the layer.xml file: hard to determine what extension points the module contribute to.'

This is just a matter of tooling: in the IDE, if you open the icons "XML Layer" and "XML Layer in context" you can see the extension points contributed by the current module marked in bold. Indeed, there's a lot of improvements that can be done in tooling (such as generating automatically dependency graphs etc...), but - again - this is a matter of tooling.

The fact that layer.xml can contain other things is very powerful indeed, and you have just to define the proper structure of virtual directories in the file itself.

 

Right. There's nothing mysterious about the NetBeans plugin mechanism at all. The ServiceLoader is a standard part of JDK 6 (and has been under the hood since JDK 1.3). The NetBeans Lookup can be used in an identical fashion. However, the NetBeans Lookup can be used in other ways too, and can be registered in additional ways (i.e., the layer.xml approach mentioned in the article). But, in essence, it follows the approach taken in the JDK completely. So it should be called "the JDK plugin mechanism (on steroids)", instead of "the NetBeans plugin mechanism".

I think the following picture provides quite a good definition of the main issues of module decoupling.

 

Nobody will argue over the advantages of the OSGI system but on the decoupling issue the mechanisms provided by NetBeans are definitely not inferior to Eclipse RCP.
To provide a clear comparison one has to think less generic. I would find a comparison between  ServiceTracker and the Lookup approach really interesting.

 

P.S I hate word 2007 ;(

Don't get me wrong, I'm an Eclipser not a NetBeanser, but ... you still have to know the extension point exists before you start. Rather than having to read a plugin.xml to work out how to create an extension, with the NetBeans approach you get Javadoc (I would imagine, I don't actually know!).

All I'm saying is, the extension point information being embedded in the plugin is not a silver bullet, if anything it's just wiring for the Eclipse registry and could be considered over the top by both OSGi and Java purists...

This whole discussion is moot IMHO - once you've maken a decision to go with one IDE or another then any pragramattic programmer will stick with that IDE and make sure they use it well.

While I love using Eclipse and even writing plugins and developing applications using RCP, the complexity of the APIs has always been a bone of contention with me.  I believe Eclipse 4 is striving to simplify that to some extent, though I have my doubts as I belive too many people are involved and last I heard they want to maintain backwards compatibility as well as add all kinds of features like a collaborative web based IDE.  Time will tell.

Anyway, in my experience it is usually the fact that NetBeans uses Swing that people don't use it.  However, I don't want to go in to the well documented issues that people have with Swing.  What I will say is that it is possible to use Swing in Eclipse plugins (actually, the integration is done at the SWT level) and that the functionality has been around for some time...

http://www.eclipsezone.com/eclipse/forums/t45697.html

 

Thanks Mr.Marton for a wonderful spicy article that made many blink their thinking bulbs :) Good to see lots of supporters supporting their front ...

I always would stick to ... if selected a technology that always looks better than the other as we have no choice to go back ... So would like to be out of the discussion ... But me a tru Eclipse Supporter and never used any other IDE or PDE for Development apart from Eclipse ... :) So i am biased towards Eclipse :p

Thought would take this opportunity to introduce myself as Malai your new Editor for Eclipse Zone and also take the chance to thnk you for a hot spot topic discussion in EclipseZone. Feel free to write to me if you require anything in Eclipse Zone ... :))

Regards

Malai

IMHO too simple layer files (only <folders>,<files>and <attr> nodes, instead of more structured description of the declaration) is the weakness of NetBeans platform. I do agree with KISS principle but IMHO NetBeans layer files go too far....and I have always said this...even when I was working on NetBeans.

By providing much stronger tooling, requiring stronger documentation and re-entrant wizards in apisupport modules could go a long way to overcome this issue.

Yes, that's right.  It is called "Declarative Services", though it has been a part of OSGi 4.0 since its release in October 2005, but hasn't been well implemented until recently. 

You effectively link to a service descriptor (XML) from your manifest file and then the declarative services implementation takes care of loading your service and injecting any required services.  It is pretty funky, though I found the Felix implementation to be unreliable.  I haven't had chance to try the new Equinox one yet, but I believe it was implemented by ProSyst, so it is bound to be good! :)

" alt-tab would give you a blank screen for a second or two,"

You're right, this happened, but in the past. For a few years, it was because of Swing being really slow. For a few years later, it was mainly because Swing programmers got used to the fact that Swing was slow and used it as an excuse for their writing bad code (I put myself in the bag, circa 2004); today if you see a bad behaving Swing application is only because it was poorly written. 

People that wish to have a quick look about how responsive can be a today's Swing application without trying it can just have a look here http://www.netbeans.tv/community/blueMarine-%40-JavaOne-2008-344/

Pardon the self-promotion :-) There are only two points in the video where I cut the time: at boot and during the opening of a picture in the full viewer; it's a "camera RAW" image and needs a few seconds to be decoded, so it's not a Swing related stuff.

According to Google Translate:

In this particular program in Eclipse IDE, and I like it. I have not be used much NetBeans, but nevertheless the structure that used to create an Eclipse RCP pleases me. I prefer Plugins and services, consider to be the most practical and give me more options on an RCP application. I prefer to use SWT and JFace on Swing, in my opinion.

"You're right, this happened, but in the past. ..." that's right. that was the reason that chooses Eclipse, NetBeans and on other IDEs, and even now has improved Swing, I keep on Eclipse. I LIKE Eclipse Platform.

Warm greetings from Merida, Yucatan, Mexico.

 

Is this what you meant?

Muito interessante a comparação sobre o Eclipse RCP e NetBeans.

 

O Eclipse RCP pode até ser complicado para muitos desenvolvedores, mas tudo que leva tempo para ser construido e para aprender, é sempre muito bom.

Vocês em todo mundo que desenvolve com esta tecnologia, deveria estar contente, pois eu aqui no Brasil é muito difícil trabalhar direto com RCP, pois no meu país não tem muito investimento para isto.

Gostaria muito de ser membro da Fundação Eclipse, mas é muito difícil conseguir essa façanha!

Luís Carlos Moreira