Skip to content


Tag: plugin



Using Eclipse-based rich-clients as stand-alone applications is discussed in many books and articles. In the context of enterprise systems, the software development adopted several paradigms to improve the quality of the overall architecture. This short article describes some issues in packaging the application for using it in the context of enterprise systems.

Architectural Assumptions

Designing enterprise architectures is a standard discipline for IT-consulting companies or freelancers involved in software development. Maybe one of the main characteristics of enterprise architectures is the framework-driven approach of software creation. Thus, the software has to comply certain rules and standards adopted inside the enterprise. In order to simplify such constrained development process, it is common to use an in-house software framework, which enforces the  compliance of the enterprise-internal standards and acts as glue between different technologies adopted as parts of the enterprise architecture.

Using such frameworks has major implications for the software development in general, and especially for the rich client development. The design issues are summarized in the next section.

Usaging an Enterprise Framework

The major goal of the enterprise in-house framework is to simplify the process of software systems development and to enforce standardization among the software systems. This usually includes the following aspects:

  • Domain-specific component framework
  • Methods for master data management
  • Infrastructure services: authentication, authorization, communication, security, printing, reporting
  • Application skeletons and launchers

The more unification and standardization is included inside the framework, the easier it is for a software developer to concentrate on the particular business task and the easier is the maintenance of the software system.

From the previous list, the most interesting part related to RCP packaging and deployment is the existence of the application skeletons and launchers. So, when launching an application, the framework libraries are loaded and executed first and pass the control to the application-specific modules. The advantage of this approach is that infrastructure services can be loaded first, which can be developed and shared among different applications.
continue reading…



This article describes some efforts to use the Common Navigator Framework (CNF). In doing so it incorporates the information already covered in different articles, but also focuses on the specific use case of providing a view of something completely unrelated to the platform resources. So the aim is not to add some content to the “Project Explorer” which is an example of resource-oriented CNF usage, but to provide a view on a completely own data model.


Project Explorer
A very common UI element to represent data is a tree view. In SWT this UI element is implemented using the Tree widget. Following the MVC design pattern in the TreeViewer, JFace simplifies the usage of the Tree widget by delegating the task of content adoption to the ContentProvider and the label production to the LabelProvider (and using Sorters and Filters for sorting and filtering). Still for a single representation one has to construct a viewer and configure it with a corresponding Label- and ContentProvider. Further code reduction can be achieved by the use of WorkbenchContentProvider and WorkbenchLabelProvider if the elements can be made adaptable (implement IAdaptable interface and making them first-class workbench citizens). This approach is helpful, if the elements has to be displayed in several different viewers (e.G. Table). Finally, the Common Navigator Framework (CNF) is a facility provided by the Eclipse Platform which allows the usage of multiple Label- and ContentProvider on the same view. The providers are activated and used dynamically and can be configured declarative or programmatically. The advantage of CNF approach is the ability to combine elements in one view which have different origins(e.G. contributed by different plugins). CNF is used in Eclipse IDE: e.G. “ProjectExplorer” and “CVS Synchrnoize” are both instances of the CNF.

The usage of the CNF in your own application for purposes of representation of resource-based (and usually file-based) content is discussed in articles of Micael Elder in detail. The main idea is to instantiate the view, declare the default content and UI interface and make some additions where needed. This post has a different aim: we start from scratch and represent completely resource unrelated content. Before diving in the implementation details, some overview is provided.

UI Overview

Project Explorer with default options There are many things which can be configured by the usage of CNF and it is beyond the scope of this post to cover all of them. Still there are several things to understand before the actual code can be written. The user interacts with a View which shows the data elements. Which elements are shown is configured using the navigation content extensions. Shown elements can be filtered with Filters and sorted using Sorters on behalf of the user. There are some predefined actions and their positions in the UI and corresponding extension points to contribute to. Project Explorer Pop-up. The actions for Working sets, Customize View, Link with editor belong to this category. The user can also right-click on particular element in the tree and sees a popup-menu. This menu is configured based on the content element and can be (is) contributed by several plugins. The action contribution is also covered in the article series from Michael Elder.

continue reading…

Eclipse RCP by default promotes the usage of a single application window with multiple views and editors inside. This default can be changed to multi-windowed application. The platform API offers several methods to operate with multiple application windows:

package org.eclipse.ui;
public interface IWorkbench ...
* Retrieves the number of opened windows
public int getWorkbenchWindowCount();
* Retrieves the array of opened windows
public IWorkbenchWindow[] getWorkbenchWindows();
* Openes a new window with given perspective
public IWorkbenchWindow openWorkbenchWindow(String perspectiveId,
IAdaptable input) throws WorkbenchException;
* Performs a perspective switch in a given window
public IWorkbenchPage showPerspective(String perspectiveId,
IWorkbenchWindow window, IAdaptable input)
throws WorkbenchException;


Using this API, opening of new windows seems simple. For example one could define a perspective, that is always opens in a new window.

Closing windows is generally performed by calling close method on the IWorkbenchWindow instance.

package org.eclipse.ui;
public interface IWorkbenchWindow ...
   * Closes the window
  public boolean close();

Unfortunaly, there is no elegant way to find out which window are you in. A workaround which uses Eclipse internal API works fine for WorkbenchWindow, which is a standard platform implementation of the IWorkbenchWindow interface.

 * Determines if the window is a root window
 * @param window a window to be checked
 * @return true, if the window is considered to be a root window
public static int getWindowId(IWorkbenchWindow window)
// HACK: note this could change in future
  if (window != null && window instanceof WorkbenchWindow))
    return ((WorkbenchWindow)window).getNumber();
  return -1;

The initial application window gets the id 1. The lookup in the implementation reveals that the internal method finds the smalles unused positive number and assigns it to the newly opened window. If you do not want to rely on this algorithm, just hash the newly created windows by they ids.


Many frameworks support plugins for increasing flexibility. They need to be loaded during runtime making it possible to change the supported features used in application without recompiling the framework and application themselves. Loading a plug-in means loading java classes, which is done by a class loader. We want to load the plug-ins from jar files, without providing a name for every JAR. Unfortunately, the java standard API does not contain a class loader for loading classes from a list of jar files in a directory. We need to provide it ourselves. In addition, the standard class loading mechanism is designed with following idea in mind: in runtime the application accesses the known classname, that is searched for in class path and loaded if found. In our case, we want to force the framework load it extensions, without setting up the class path before applications starts, which is a little different use case.

Simple JAR class loader

The first step is loading classes from jar files. For this purpose we create a class named JarFileClassLoader which should be able to load a class from a jar file. It inherits from ClassLoader, the Java default implementation for a class loader. Loading a class from a jar file means scanning each jar file entries, decide if it is a class then load it. Because we want to be flexible about the criterion we use to select our classes, we introduce an interface ICriterion, which decides for a given class if the criterion is fulfilled or not. Using this, the JarFileClassLoader can now scan a single jar file and load every class fulfilling the injected criterion. Loading a class means scanning the caches of the parent class loaders, calling the loadClass(String) method of the parents if not found and scanning the jar file afterwards if the class was still not found. This beahviour is described in a previous post, introducing the basics of Java Class Loading.

JarFileClassLoader is capable of loading a class if it does not reference other classes. These references have to be resolved during class loading time. Let consider the example of classes A and B where A references B. If A is loaded by a class loader CL, CL is asked for loading B also. This is done by calling the loadClass(String) method of CL. If B is contained in the jar file CL loads classes from, CL will find it and return it to the JVM. If B is not contained in CL’s jar file, CL’s parents are asked to load it. Thus the class will be loaded if it is contained in the classpath where one of the java class loaders will find it. If the class is contained in another jar file in the list, but not in the class path it will not be found and the loading will end with a ClassNotFoundException.
Plugin Class Loader

Plugin class loader

To tackle this problem we introduce another class, the PluginLoader. It contains a collection of JarFileClassLoaders and inherits from ClassLoader, thus is a ClassLoader itself. The PluginLoader acts as a parent for all JarFileClassLoaders and is therefore asked every time a class has to be loaded. It will then iterate over all JarFileClassLoaders calling the loadClass(String) method on all of them to find the class it looks for. This way, classes contained in sibling class loaders are found also without violating the rule that a class loader can only see classes of itself or its parents.

Putting everything together

Now the structure of our plug-in loader component becomes clear. What we additionally need to do, is get rid of all the stack overflows we produce with the above classes. The problem here is that any JarFileClassLoader asks its parent, the PluginLoader, to load a class. This will ask all child JarFileClassLoaders to load the class including the CL which asked the PluginLoader before. The result is an infinite call stack loop – a stack overflow. Therefore we relax the concept of the java class loading. We introduce a method loadClassSimple(String) on the JarFileClassLoaders which looks just in its very own jar file. If it does not find the wanted class it just throws an Exception without asking a parent or cache-lookups. This method is called by the PluginLoader only, therefore the rest of the class loading is not affected.
Plugin Class Loader at runtime
Last but not least we consider some performance issues. If a class is searched in other jar files, those have to be scanned every time again resulting in poor performance. Therefore we introduce a cache in the JarFileClassLoader containing every class that was loaded before. Every request is served now by trying to find the class in the cache first.


Due to the fact, that PluginLoader asks its child JarClassLoaders to load a class in particuliar order, and the first class found will be taken, the order in which JarClassLoaders are asked matters. This issue can cause problems if e.G. different versions of the same library are deployed on location scanned by the PluginLoader and should be handled with care.


  • [2007,book] bibtex Go to document
    G. Krueger and T. Stark, Handbuch der Java-Programmierung, , 2007.
      author = {Guido Krueger and Thomas Stark},
      title = {Handbuch der Java-Programmierung},
      month = Nov, year = {2007},
      url = {} publisher = {Addison-Wesley} isbn = {3-8273-2373-8}
  • [,techreport] bibtex Go to document
    "Java Class Loading: The Basics,".
    @techreport{CL_BASICS author = {Brandon E. Taylor},
      title = {Java Class Loading: The Basics},
      url = {}