JavaA First Look at Eclipse Plug-In Programming

A First Look at Eclipse Plug-In Programming

“First they ignore you, then they laugh at you, then they fight you, then you win.”—Mahatma Gandhi (1869-1948)

1. Introduction

1.1. What is Eclipse?

The Java platform is extensively used on server and enterprise applications. Java is even used on systems that require high performance. Despite its extensive use on server platforms, it has not been used too much on desktop applications. The main reason is the look & feel of the Java applications. Most end-users find Java look & feel differently then the one what they are accustomed to. After the introduction of Swing, there were many new things that a programmer can control and use.

On the other hand, platform-dependent integration was still missing. It was still hard to use MSOffice tools with Swing.

Eclipse solves the problems that exist in the current Swing library. The SWT library provides a platform-dependent look & feel. In addition to that, Eclipse provides a plug-in based framework that can be used as a base platform for desktop applications.

1.1.2. Who is behind Eclipse?

IBM has started to develop a project called Eclipse. IBM invested 40 K dollars before giving it away to the open source community. The first release of Eclipse V 1.0 wass announced in November 2001. Eclipse is supported by many other organizations such as Borland Software Corp., Merant Internation Ltd., Oracle, Rational Software Corp., Red Hat Inc., SuSe Inc., and TogetherSoft Corp.

1.1.3. What makes Eclipse unique?

Eclipse is a set of frameworks that brings Java applications to the desktop. In contrast to many other open source projects, Eclipse is supported by many big companies.

SWT (The Standard Widget Toolkit) library delivers native widget functionality for the Eclipse platform in an operating system-independent manner. The SWT library can be used to provide native look and feel to the end-users. End-users don’t know whether the application is a Java application or a native application.

The Eclipse platform delivers plug-in–based architecture. Everything except a small bootstrap code is written as a plug-in in Eclipse. The Eclipse platform architecture includes all the GUI design patterns. For example, it provides plug-in versioning, a help system, and so forth. It can also be used as general purpose IDE architecture. Eclipse Java IDE is based on generic plug-in architecture, which makes it easy to support other languages as well.

Through its predefined infrastructure, different vendor plug-ins can communicate with each other easily.

1.2. Where to start?

Eclipse has its own GUI library (SWT) that provides a native look and feel for Eclipse. Eclipse code is written in Java that calls the SWT library through JNI. Eclipse does not ship with a JVM. To use Eclipse, a JVM must exist on the target platform. Otherwise, you will get the following error message.

Figure 1. Error message shown when there is no JVM installed.

To develop under Java, it is better to download and install a JDK.

Eclipse can be found on the Eclipse download Web site at no charge. I would suggest you download the latest release build (Build name: 2.1.2) of the “Eclipse SDK” from the main Eclipse download site.

Eclipse workbench uses the native SWT library. Therefore, appropriate target platform download should be selected for the download. The SWT library supports the following platforms:

Table 1. SWT Platforms
Operating System Windowing Sub-system
Windows 98/ME/2000/XP/CE Win32
Linux Motif
Linux GTK
Solaris Motif
MacOS Carbon
QNX Photon
AIX Motif
HP-UX Motif

After downloading and unzipping the Eclipse zip file it should be started by running the Eclipse executable file found under the top-level installation directory.

Changing the workspace location
You can specify different workspace locations by using eclipse.exe -data <location> as a command line parameter of the Eclipse executable.

The default location of the workspace is the root installation directory of the Eclipse installation. If you want to run different instances of Eclipse for different projects or purposes, you can do the following:

  1. Create an Eclipse shortcut.
  2. Give a proper name to the shortcut.
  3. Right-click on the shortcut and open the Properties window.
  4. Set the “Start in:” parameter of the shortcut to a new location. Eclipse will use this location as the workspace.

1.3. Projects under

There are different projects developed under The picture below shows these projects.

Figure 2. The project structure

Eclipse project provides industry-standard, commercial-quality integrated tools. The Eclipse project consists of three sub projects. These are:

  • Platform (core—plug-in based architecture)
  • JDT (Java Development Tools)
  • PDE (Plug-in Development Environment)

Eclipse JDT is very good tool at no cost. It provides much functionality, such as syntax highlight, code refactoring, debugger, team environment, and scrapbook.

PDE provides the tools to write plug-ins. PDE makes it easy to write a plug-in within a plug-in environment. You can write a plug-in easily. PDE runs your plug-in within another Eclipse instance. It also allows you to select the plug-in to be included in your application.

Eclipse tools project provides a central place for tool builder for the Eclipse platform.

Eclipse technology project provides new channels for open source developers, researchers, academics, and educators to participate in the on-going evolution of Eclipse.

“Eclipse officials said that the new organization will work and look a lot like the Apache Foundation and that members will have to commit to provide a commercial product that supports Eclipse within 12 months of joining.”

1.4. First impression

The first thing that you will notice is its user interface. The user interface looks neither like a Windows application nor a Java application. Eclipse itself is written in Java, but the user interface framework (SWT, JFace) of Eclipse is written in native Language. This significant property of Eclipse seems to bring extensive use of Java desktop applications into scenes.

On the other hand, code that is written in a native language is no longer platform independent. For that reason, a proper platform-specific version of Eclipse should be downloaded to run on different platforms.

Eclipse should not be thought of as an alternative to Sun’s Swing, AWT framework. Besides its UI libraries, Eclipse has studied many user interface design patterns and those patterns are used in the Eclipse architecture. Developers will notice many common design patterns in the Eclipse code. Plug-in based architecture makes it easy to extend the Eclipse platform or integrate tools, including your own tools, into the Eclipse platform by writing plug-ins.

1.5. The SWT Architecture

The Java AWT library uses Java and C libraries to provide platform independence. The user interface is written by Sun. There is no direct call to the windowing sub-system of the host operating system. This provides a level of platform independence. The AWT library was not very flexible and some components were missing. For that reason, Swing is developed on the top of AWT library. It provides more flexibility then AWT.

Figure 3. Swing and SWT architectures

On the other hand, the performance and look & feel of the existing Java GUI API have not convinced IBM and they have started to write a new GUI library, called SWT. The SWT is simpler and faster then the Swing library. The look & feel is the same as the host platform. It uses JNI, with the help of small native SWT code, to call the existing windowing sub-system on the host platform.

Advantages of the SWT library:

  • Look & Feel does not differ from other native-written applications on the host platform
  • Simple API
  • Faster
  • Emulates unavailable widget under the host platform

Disadvantages of the SWT library:

  • Requires SWT native libraries on the target platform
  • Not as flexible as Swing
  • The AWT base APIs cannot be used under SWT, such as Java2D, Java3D, and Java Advanced Imaging APIs
1.5.1 SWT and system resources

Swing simulates the GUI components and GUI resources are disposed of by the Java garbage collection mechanism.

In contrast to Swing, system resources must be disposed of after using them in SWT. Basically, keeping in mind the following two rules will help in efficiently managing GUI resources:

  1. If you create a GUI component with SWT, such as Button, Text, List, or Combo, you have to dispose of it.
  2. Disposing of a parent Composite disposes of the children. Because the fonts and colors are not part of a composite, they must be disposed of manually.

In the Eclipse workbench, disposing of the workbench window disposes of child composites. The Fonts and Colors are not a part of a composite; therefore, in the Eclipse workbench, they must be disposed of.

1.6. Eclipse Architecture

A simplified variant of the Eclipse architecture can be seen below. The Eclipse platform has a small micro kernel. Except for this small micro kernel, everything is written as a plug-in. Each plug-in is loaded by this small micro kernel.

Figure 4. Eclipse plug-in Architecture

Eclipse has plug-in architecture. Developers can extend Eclipse by writing extensions to the predefined extension points.

The Eclipse core is responsible for:

  • Booting and running the platform
  • Plug-in declaration and management
  • Resource management

The core module is generic. It behaves equally to all plug-ins. It does not know any domain-specific information. It can run equally well with or without a GUI.

The Eclipse user interface defines the building blocks of the user interface. It can be divided into three groups—workbench, JFace, and SWT. From the user’s point of view, a workbench is the main window of Eclipse. It consists of views, toolbars, menu bars, and editors. The purpose of the workbench is to facilitate the integration of the tools. These tools use extension points to contribute to the workbench. JFace is a smaller set of UI frameworks for handling common user interface programming tasks. JFace is designed to work with SWT without hiding it. SWT defines a set of widgets that form the basis of integrated tools build with Eclipse.

1.6.1 Eclipse startup

Eclipse contains an executable called eclipse.exe under the root directory of the Eclipse installation. The executable binary file allocates an amount of memory and launches the org.eclipse.core.launcher.Main application, located in startup.jar, from within its allocated memory. This startup file is in the same directory as the Eclipse executable.

The source code of the startup.jar file is located under the org.eclipse.platform plug-in directory of the Eclipse source code. In binary Eclipse, this plug-in only contains the splash screens and icons of the Eclipse platform. This jar file only contains one Main class that loads the platform. The package name of the class is org.eclipse.core.launcher.Main, which is different from the plug-in name.

If the boot <URL> option is not specified as a startup parameter to the Eclipse binary executable, the startup.jar will load the org.eclipse.core.boot.BootLoader by default. This class is responsible for loading the platform runtime.

The org.eclipse.core.runtime package is the main player.

The Eclipse.exe file is a platform-specific binary file. By default, it runs org.eclipse.core.launcher.Main, which is located in the startup.jar file.

You can only run one instance of Eclipse with one workspace. If you want to run another instance of Eclipse at the same time, you need to specify another workspace location as the startup parameter to theeclipse.exe binary executable file.

1.7. Eclipse vocabulary

It is helpful to learn a little Eclipse vocabulary before getting into it. The picture below shows a workbench window.

Figure 5. Eclipse Workbench Window

  • Workbench—from the end-user’s point of view, a workbench is the main window of Eclipse.
  • Parts—a set of views or editors in a workbench window.
  • Perspective—defines tje layout and initial set of views and editors (parts) in a workbench. The Shortcut bar shows a list of perspectives.
  • Extension point—a place where you can extend an existing functionality.
  • Extension—a thing with which you extend an existing functionality.
  • Display—represents the connection between SWT and the underlying platform’s GUI system.
  • Shell—a window managed by operation system’s window manager.

2. Plug-in development

2.1. Setting up Eclipse

Developing plug-ins is different than developing a pure Java application. Apart from the JDT, PDE tools are also provided to develop plug-ins for the Eclipse platform.

You need to use other plug-ins defined by the Eclipse platform. Those plug-ins must exist in your class path. Instead of importing all plug-ins as a Java project, PDE provides a space-efficient way to use them; you cannot modify the plug-in code, but you can browse.

To set up your workspace, you need to do the following:

  1. Switch to the appropriate perspective: Window->Open Perspective-> Java
  2. Figure 6. Perspective Selection

    Associated perspective
    If you create a new project, Eclipse will ask you to switch to the associated perspective of the created project.
  3. Import the necessary plug-ins through a widget: “File->Import…->External Plug-ins and Fragments”.
  4. Figure 7. Plug-in Import

    Accept the default values on the second page. The third page shows the available plug-ins. Choose “Select All” to import all the plug-ins into your workspace. Click finish.

    Figure 8. Selection of the Plug-ins for Import

    Afterwards, plug-ins will be copied into your workspace and they will be available in the classpath. You can see the imported plug-ins and their source code from “Window-> Open Perspective -> Plug-in Development.”

    Importing plug-ins
    If you skip that step, the Eclipse plug-in creation wizard will import the required plug-ins that are needed to compile the plug-in.

2.2. Creating a Plug-In Project

Developing a plug-in project is different than developing a normal application. A plug-in project needs to be created before starting to develop a project. To create a plug-in project, choose “File-> New -> Project…-> Plug-in Project”.

Figure 9. Creating a Plug-in project

Give a project name on the second page. Accept the default values on the third page. On the fourth page (see Figure 10), select “Create a plug-in project using a code generation wizard” and “Hello, World”. Click Finish on the fifth page.

Figure 10. Plug-in code generator

We have created a plug-in project successfully. The structure of the project can be seen below. The plug-in creation wizard has created one plug class, one action class, and the necessary resource files.

Figure 11. Plug-in Structure

To test your project, you need to run the project as a Run-time Workbench by using “Run->Run As->Run-time Workbench”. A new Eclipse instance will be started and your plug-in will be ready to use in this instance. The running instance will contain the HelloWorld Plugin and the toolbar contribution of the plug-in will be shown. Figure 12 shows the second running instance of the Eclipse application.

Figure 12. Toolbar contribution

Should you need to see the loaded plug-in, you can use “Help->About Eclipse Platform->Plug-in Details”. You can find the HelloWorld plug-in in the list as well, which means that our plug-in is loaded properly.

Figure 13. A list of loaded plug-ins

3. Inspecting the generated source

3.1. Plug-in Manifest file

Eclipse doesn’t load all the plug-ins until they are needed. The plug-in manifest file provides Eclipse with a definition of the plug-in. The plug-in manifest doesn’t contain any internal details. It is only a shadow of the real plug-in implementation.

Figure 14. Plug-in manifest file

Eclipse reads all the plug-in manifest files at startup and keeps them in the plug-in registry. When the plug-in required, it loads and instantiates the plug-in.

3.1.1. Plugin tag
 Source 1. plug-in.xml
   <?xml version="1.0" encoding="UTF-8"?>
     name="HelloWorld Plug-in"
  provider-name="Koray Guclu"

The code listing above shows the manifest file of the hello world application. It is an XML file. It contains information about the plug-in.

The plugin id is defined. The plug-in id is must be unique. But, the name of the code listing tells that plug-in's unique id is de.korayguclu.eclipse. The id must be unique, but the name of the plug-in can be anything.

Plug-ins can have versions and other plug-ins can depend on a specific version of another plug-in.

The provider name of the plug-in is displayed on the plug-in listing window. Refer to Figure 12.

The class name is import. It defines the plug-in class. The class must comply with the definition of a plug-in. Just like a gear on Figure 14, in order to run properly with the existing system, a plugin must also conform to the rules defined by the system. For that reason, plug-in class extends from org.eclipse.ui.plugin.AbstractUIPlugin.

 Source 2.
   package de.korayguclu.eclipse;
   import java.util.*;
import org.eclipse.core.resources.*;
   import org.eclipse.core.runtime.*;
import org.eclipse.ui.plugin.*;
   public class HelloWorldPlugin
       extends AbstractUIPlugin

Source 2 above shows the Java source of the plug-in. As you can see, the HelloWorldPlugin class extends the AbstractUIPlugin class.

Figure 15. HelloWorldPlugin inheritence

3.1.2. Runtime tag

Runtime tag defines the libraries required by the plug-in execution at runtime. If you need to use other libraries in your plug-in, you can copy them under the root directory of the plug-in and write your plug-in name in the runtime tag.

 Source 3. plug-in.xml, runtime tag
  <library name="eclipse.jar"/>


 HelloWorld plugin's class files are in the eclipse.jar file. They are required at runtime. For that reason, we have to at least write the name of the jar file containing the plug-in class files here.

3.1.3. Requires tag

The requires tag defines the dependency of the plug-in. The requires tag defines the runtime dependency of the plug-in. If the tag is not correctly defined, you might be able to compile your plug-in but not run it.

 Source 4. plug-in.xml, requires tag
  <import plugin="org.eclipse.core.resources"/>

  <import plugin="org.eclipse.ui"/>

The HelloWorld plug-in depends on the org.eclipse.core.resource plug-in and depends on org.eclipse.ui plug-in. To use the import org.eclipse.core.resources.*statement and the org.eclipse.ui.plugin.* in Source 2, you need to define the plug-in IDs of these APIs in the requires tag.

We define the ID of the required plug-in in the require tag. This definition enables us to use the API classes of the plug-in. Table 2 shows the list of used APIs and plug-in IDs of the HelloWorld plug-in. The API package is the package that we import in our plug-in classes. The plug-in ID is the ID that we need to define in the requires tag. The org.eclipse.core.boot and org.eclipse.core.runtime plug-ins are special plug-ins. They are automatically defined as prerequisites of every plug-in. Therefore, their API packages are always available.

Table 2. Map of used platform plug-ins
API Package plug-in id
org.eclipse.core.resources org.eclipse.core.resources
org.eclipse.core.boot org.eclipse.core.boot

If the requires tag is not correctly set, Eclipse might show something similar to the following error message in the console view.

 Console output
Could not create action delegate for id: de.korayguclu.eclipse.actions.SampleAction
Plug-in de.korayguclu.eclipse was unable to load class de.korayguclu.eclipse.actions.SampleAction.
3.1.4. Extension tag

An extension tag is used to extend an existing functionality of the another plug-in or Eclipse platform. The HelloWorld plug-in defines two extensions to add additional functionality to the existing extension points. The first extension defines new action sets and the second extension is used to add the first extension to the default (resource) perspective.

 Source 5. plug-in.xml, requires tag
<extension point="org.eclipse.ui.actionSets">
      label="Sample Action Set"
      <menu id="sampleMenu"
            label="Sample &amp;Menu">
        <separator name="sampleGroup"/>
       label="&amp;Sample Action"
        tooltip="Hello, Eclipse world">
<extension point="org.eclipse.ui.perspectiveExtensions">
    <actionSet id="de.korayguclu.eclipse.actionSet"/>


Java is strong on server platforms. Eclipse will bring Java to the desktop. Being an open source project will spread the use of Eclipse quickly. It makes it easy to improve the existing code or to adapt the existing code of the Eclipse platform.

Just like enterprise Java beans, Eclipse is a good candidate to be a container for a desktop application of the plug-in developers.

Many open source tools have been successfully used in business. Linux, Apache, JBoss, and StarOffice are examples of successful open source projects.

About the Author

Koray Güclü

He is working as a freelance author and software architect. He is currently finishing his book on Software Architectures and Design Patterns. His main interest areas are Software Architectures, Data Warehouses, and Database Modeling.



I would like to thank to Steve Gaiser for his valuable efforts in reviewing this text.



Get the Free Newsletter!

Subscribe to Developer Insider for top news, trends & analysis

Latest Posts

Related Stories