Marton has posted 2 posts at DZone. View Full User Profile

NetBeans vs. Eclipse RCP: Plugin Mechanism Comparison

10.14.2008
| 19369 views |
  • submit to reddit

NetBeans and Eclipse approaches extension points and extensions differently. Let us see what these differences are.

Please note, that this article is meant for those who already have suitable knowledge on both platform's plugin mechanisms.

NetBeans Platform:

Defining an Extension Point

Create an interface, and put it into a module-public package.

Creating an Extension

Create an implementation for the interface, and register it in the virtual file system of the layer.xml file.

Reading available Extensions

Use the org.openide.util.Lookup class to obtain instances of the interface implementations.

Eclipse RCP:

Defining an Extension Point

Create an extension point descriptor schema, that defines extension point elements and their attributes, as well as the relationship of these elements.

The following attribute types are available: boolean, string, java, resource, identifier.

Documentation can be added to any part of the schema.

Finally, register your extension point in the plugin.xml file.

Creating an Extension

In the plugin.xml file create a section according to the schema, where the attributes get their values.

If attribute type is java, create the referenced java class as well.

Reading available Extensions

Use the org.eclipse.core.runtime.IExtensionPoint to get the list of extensions. From each extension obtain the list of IConfigurationElements: each IConfigurationElement corresponds to an XML tag in the plugin.xml file.

 

NetBeans Platform

Eclipse RCP

Advantages

Disadvantages

Advantages

Disadvantages

Very simple, easy to learn.

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

The extension point clearly defines itself: a quick look into the jar file and you immediately know what extension points the plugin provides and what elements are they consist of.

More complex, more time to learn.

 

The lookup name to be used is also undefined.

Many attribute types: possible to describe certain structures in XML.

 

 

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

Possible to generate most part of the extension: see PDE

 

 

 

Well defined place for documentation.

 

Published at DZone with permission of its author, Marton Sigmond.

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

Comments

Geertjan Wielenga replied on Tue, 2008/10/14 - 3:37am

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.

Christopher Brind replied on Tue, 2008/10/14 - 5:04am in response to: Geertjan Wielenga

And from the Eclipse point of view, you don't really discuss the fact that Plugins are just OSGi Bundles with a bit extra, namely a plugin.xml and an inherent dependency on the Equinox Plugin registry, which as it happens you can re-use outside of Eclipse in other OSGi frameworks.  Ergo, you can actually create additional functionality for the Eclipse IDE (and RCP applications) using a pure OSGi approach.

Fabrizio Giudici replied on Tue, 2008/10/14 - 5:13am

"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.

 

Toni Epple replied on Tue, 2008/10/14 - 5:13am

You're missing the main advantage of the NetBeans approach:

 "Portability & Standards conformance: As long as you're using ServiceLoader you can reuse your jars without the platform and without any changes."

As Geertjan said: NetBeans supports the standard defined in the JAR specification, therfore you can take your API and IMPL jars and reuse them everywhere.

Cheers,

Toni

Geertjan Wielenga replied on Tue, 2008/10/14 - 5:35am in response to: Toni Epple

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".

Mickael Baron replied on Tue, 2008/10/14 - 5:43am

Hi,

Thanks for this comparison, there is few article about this kind of cool topic.

If i may submit a comment you can enhanced the reading available extensions part of Eclipse RCP by using the IExtensionRegistry class to retrieve all extensions and extension points.

Keulkeul (http://keulkeul.blogspot.com)

 

Pavel Kotlov replied on Tue, 2008/10/14 - 8:22am

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

 Extesions & services

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 ;(

Marton Sigmond replied on Wed, 2008/10/15 - 2:12am in response to: Fabrizio Giudici

"... the only thing I need to know is that there is an extension point ..."

The question is: do you know if there is an extension point?

In the case of NetBeans where would you get this information from? All you can see is module-public interfaces.

In the case of Eclipse though this information is embedded into the plugin.

Christopher Brind replied on Wed, 2008/10/15 - 2:52am in response to: Marton Sigmond

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.

Fabrizio Giudici replied on Wed, 2008/10/15 - 3:11am

Hmm, I still don't understand the question :-)So let's go with examples from my use cases.

Case number 1: the extension point is a service: client code needs a service S, thus it must know the interface that describes it and the interface itself is the name to pass to lookup. Since I must invoke methods in S, I must have prior knowledge of S.

Case number 2: the extension point is a listener, so the original code is not aware of it; the idea is that you can extend an existing functionality by putting into the system a new plugin, so the original code is not aware of the presence of the listener. But - the listener would be still described by an interface. The original code lookups for that interface and gets a list of implementations (possible multiple listeners) and calls them. In this scenario, the original code doesn't know whether there are zero extension points, or there are multiple ones. Still, by looking up a class we fall back to the previous case.

BTW, with the Module API in NetBeans you can actualy inspect all the modules you have in the system. At the moment I can't figure out a use case for that (apart from the plugin management facility). Can you make some example of what you're thinking of?

Christopher: clearly when one has choosen (or has been forced to use) a platform, he sticks with it. But sometimes he can choose; for instance, I evaluated the Eclipse module system in 2005 (at the time Eclipse was my IDE) since my application was plain Java. While the fact that Eclipse is not Swing played a major role in my rejecting it, I also found the module system thing pretty overcomplicated. After a few months I tried NetBeans, and sure the initial facilitator was Swing compability that made it easier to port my old code; but I really found the module system intuitive and easy to understand and use.

 

Christopher Brind replied on Wed, 2008/10/15 - 3:51am

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


 

Fabrizio Giudici replied on Wed, 2008/10/15 - 7:20am

I know, but bridges often stop working after the demo :-) And BTW in that year there was the Mac PPC -> Intel switch that caused all kind of troubles to SWT. In the end, while Swing drove my choice (I would argue against the fact that people don't use Swing ;-) but it's off topic here), I'm happy because of the platform.

Annamalai Chock... replied on Wed, 2008/10/15 - 9:08am

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

Geertjan Wielenga replied on Wed, 2008/10/15 - 9:45am in response to: Christopher Brind

[quote=brindy]

Anyway, in my experience it is usually the fact that NetBeans uses Swing that people don't use it. 

[/quote]

 

But that is also exactly why those who DO use it use it. Every customer I've ever spoken to has mentioned "NetBeans Platform is Swing" as the 1st reason why they chose the NetBeans Platform over Eclipse RCP.

Sandip Chitale replied on Fri, 2008/10/17 - 4:20pm

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.

James Ervin replied on Fri, 2008/10/17 - 3:58pm

As I was glancing down the discussion, I found the part about how NetBeans does services kinda interesting.  Why?  Well I am an Eclipse guy and I like to know what the other half does for one.  The other reason is that alot of what is described about defining an interface and so on, is just as applicable to the underlying OSGi container for Eclipse.  You don't have to use extension points, but rather you can use OSGi services.  Of course, the last time I did so, it still required you to programmatically register and bind the services to the container, but I believe it can be done in a declarative fashion in the manifest.mf now.  But at least it gives me additional reason to keep paying attention to the new Spring Dynamic Modules effort.  You go guys!!

 

Christopher Brind replied on Fri, 2008/10/17 - 4:18pm in response to: James Ervin

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! :)

Christopher Brind replied on Fri, 2008/10/17 - 5:13pm in response to: Geertjan Wielenga

I wonder if there is a general consensus then, that a developer's primary choice of IDE comes down to experience of using Swing applications?

I used to enjoy writing Swing applications, but a lot of the ones I used that other people wrote seemed really slow... alt-tab would give you a blank screen for a second or two, you could type faster than input fields could display them and so on.  My (limited) experience of NetBeans was just as such. 

I should probably give it a try now, but there are some reasons why I won't:

- Eclipse works great for me.  It isn't broken, so I won't fix it.
- I use Flex Builder 3, which as a plugin for Eclipse means I have a single environment to work in
- A bunch of other plugins that I love using are probably not available for NetBeans (or I can't be bothered finding out anyway)
- NetBeans uses Swing =)

Fabrizio Giudici replied on Sat, 2008/10/18 - 3:50am in response to: Christopher Brind

" 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.

ALFREDO CHALE replied on Mon, 2008/10/20 - 10:16am

En lo particular programo en Eclipse IDE, y me gusta. No he utilziado mucho NetBeans, mas sin embargo la estructura que utiliza eclipse para crear un RCP me agrada. prefiero los Plugins y Servicios, considero que son mas practicos y me dan mas opciones sobre una aplicacion RCP. Prefiero Utilizar SWT y JFace sobre Swing, en mi opinion.

" You're right, this happened, but in the past. ..." asi es. esa fue la razon por la que opte Eclipse, sobre NetBeans y otros IDEs, y aunque ahora ha mejorado Swing, sigo sobre Eclipse. I LIKE Eclipse Platform.

 

Saludos calurosos desde Merida, Yucatan, Mexico.

 

Marton Sigmond replied on Tue, 2008/10/21 - 6:31am in response to: ALFREDO CHALE

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?

James Ervin replied on Tue, 2008/10/21 - 10:12am

Hey kudos to Google translate, that aint too bad.  Basically he said that even though Swing has gotten better, he still prefers the JFace/SWT toolkit and Eclipse, particularly for RCP development.  I think if he had the chance he would give the underlying OSGi container some love too.

Luis Carlos Mor... replied on Tue, 2008/11/11 - 5:15pm

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

Marton Sigmond replied on Fri, 2008/11/14 - 11:33am in response to: Luis Carlos Moreira Da Costa

Yeah! And now it is my turn... in Hungarian!

Comment viewing options

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