Over a million developers have joined DZone.

NetBeans vs. Eclipse RCP: Plugin Mechanism Comparison

DZone's Guide to

NetBeans vs. Eclipse RCP: Plugin Mechanism Comparison

· Java Zone
Free Resource

Microservices! They are everywhere, or at least, the term is. When should you use a microservice architecture? What factors should be considered when making that decision? Do the benefits outweigh the costs? Why is everyone so excited about them, anyway?  Brought to you in partnership with IBM.

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





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.


Discover how the Watson team is further developing SDKs in Java, Node.js, Python, iOS, and Android to access these services and make programming easy. Brought to you in partnership with IBM.


Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}