Dimitri Missoh
enthusiastic technologist and problem solver

June 10th, 2015

Lightweight in-memory Database

Last time I was looking for a really simple and lightweight key-value cache and store based alternative to redis. I found MapDB. The use is quite simple and the biggest plus is the possibility to persist the data in the file system. It’s up and running with 6 lines of code.

To add the Maven dependency:

To use it:

December 20th, 2009

Aspect Oriented Programming with Object Teams/Java (Part I)

Aspect Oriented Programming (AOP)

The goal of Aspect Oriented Programming (AOP) is to improve the modularity in a software by offering the possibility to separate concerns. It provides another level of modularity in a piece of software.
A concern (also known as cross-cutting-concern) can be defined as a functionality or a coherent grouping of reusable functionalities that are (or can be) scattered over a software. Common examples of concerns are:

  • caching and
  • logging

In a classical object oriented architecture the programmer groups the functionalities of the software in modules, e.g. there would be a module that implements the persistence, another one to handle the login and so on.

In each of these modules you will definitely find recurrent pieces of code that are responsible for loggin or caching of important information/data.

Cross-Cutting Concern

The idea behind AOP is to extract and centralize this common functionalities (cross-cutting-concerns) in the so called aspects. The figure below visualize the notion of crossing-cutting-concern using the example of loggin.

Cross-Cutting Concern

Weaving strategies

The role of an AOP implementation is to provide a way to intercept method calls and define a set of rules to interact with the base code (the non aspect part). The term used to denote how the aspect code is “integrated” into the programming language is called weaving. The aspect code will be woven into the base code. Well-known weaving strategy are:

  • Compile-Time Weaving (CTW)
  • Load-Time Weaving (LTW)

Compile-Time weaving is the simplest one to implements, where the aspect compiler combines and compiles both the base and the aspect code to generate the woven classes.

Load-Time weaving operates at the byte code level. Every time the class loader is asked to return a given class, aspects are injected in the byte code (e.g. through the use of byte code instrumentation).

AspectJ and Equinox Aspects

One implementation of AOP for the Java programming language is AspectJ. The AspectJ Development Tools (AJDT) provides an excellent Eclipse platform based tool support for AOSD with AspectJ. From the need of supporting the use of AspectJ in OSGi, especially in Equinox (e.g. for Eclipse based applications), the Equinox Aspects project was born. For impatients, this quick start is a nice warm up to begin using Equinox Aspect.

I will not go deeper into Equinox Aspect, but rather give more details on Object Teams/J my favorite one.

Notes: For details on how AspectJ addresses weaving issue, please read this documentation.

Object Teams/Java

What is Object Teams/J?

As we saw in the previous session of this article, the aspect oriented paradigm has been introduced on the top of OOP to enhance the concept of modularity by providing a means to extract and centralize a concern. Object Teams goes the exta mile and provides a very interesting approach for the modularity and especially for the reuse of components. Although I’m only interested in OT/Equinox which is the integration of OT/J into the  Eclipse Equinox framework, I will give you in the next paragraph a short overview of the concepts behind OT.

OT defines two new construct for the programming language:

  • Team
  • Role

A Team is a grouping mechanism for collaborative units called Roles. I.e. a Team is aim to contains a set of Roles that interact with each other. A Role can not only interact with other Roles within a Team, but also can be bound to a base class. This bindings between a Role and a given base class can be defined using the relation ship called playedBy.

Two kind of method bindings have been defined:

  • callout binding
  • callin binding

Callout binding: Method calls done on a method of the Role will delegate this call to the method of the bounded base class. It works like a classic method inheritance in OOP. I.e. a callout binding just forward to the base.

Callin binding: A method invocation done by client code on a base class  will be intersected and redirected to the bounded Role-method. I.e. a calling binding intercept base methods. Callins are the aspect oriented part of Object Teams framework.

A Team, a Role, a Callin and a Callout are the most important concepts Object Teams is made up of. The figures below show how standard software pieces (in gray) interaction with a Team.

The principle of the Object Team framework.

The figure below shows a more detailed overview of how a OT projects interact with other software components.

A detailed overview of the OT interaction with other components.

In the example below, the rule ‘roleMethodY <- methodY‘ (in red) defined in the Team ‘MyTeam‘ is aim to intercept all method calls done on the method  ClassX.methodY(). If e.g. the method ClassZ.methodZ() try to call the method ClassX.methody() (see the sted (1) on the figure above), this call will be intercepted by the method MyTeam.Role2.roleMethodY() (see the step (2) and (3)). The method MyTeam.Role2.roleMethodY() is executed instead.

This is a typical example of a callin binding.

At the other hand, the developer would like to reuse some components (e.g. the logic implemented in the method ClassX.methodX()) in it Team implementation. E.g. a method implemented in the Role 1 calls the method Role2.roleMethodX() (see the step (a)). The developer knows that the logic he needs in the method Role2.roleMethodX() has already been implemented in the base class ClassX.methodX() and would like to reuse it. To solve this problem he just has to define the new rule ‘roleMethodX -> methodX‘ (in green), i.e. a callout binding (see the step (b)) that just forward the method invocation to the base method ClassX.methodX() (step (c)).

This is a typical example of a callout binding.

Here is quick update: I found a very nice blog entry describing the main concepts of OT in few words. It also explain how OT can be used on top of existing software modules to create new specializations (in form of Team grouping a set of Roles) to solve new problems without breaking the old architecture. The few diagrams on this blog show in a very nice way how Teams and Roles are aimed to enhance the modularity of a software. Have a look at: http://blog.objectteams.org/2010/07/object-teams-final-070/.

Let’s have a break

This should be enough for the theoretical part of this article, in one of my next post I will try to illustrate the power of the Object Teams framework with a very simple and comprehensive example based on a RCP project.

P.S.: The article Eclipse RCP for dummies shows have to build a simple RCP application in less than 2 minutes.

August 2nd, 2009

BioLogic is out!

The logo of BioLogic

I’m happy to announce that the first version of BioLogic is out, and is available for download on SourceForge.

BioLogic is an Eclipse based RCP application I have developed for behavioral observation. The idea is based on Observer, a DOS application used for the same purpose. The aim of this application is to ease the work of scientists who want to record events during a behavioral observation.

An example of an observable process can be different behaviors a bumble bee shows when regulating brood temperature.

The example above is a real life Use-Case where BioLogic has been successfully utilized. At the Department of Behavioral Physiology & Sociobiology (University of Wuerzburg), BioLogic has been tested for the first time during experiments performed with bumble bees.

BioLogic allows the user to record, log, visualize, export and backup events collected during an experimental run.

The following screenshots give you an idea of the whole application:

The screen you seen when your start the workbench for the first time.

The screen you seen when your start the workbench for the first time.
The application's Quick Help.

Application’s Quick Help
Sequence recorded with the workbench.

Sequence recorded with the workbench.
The graphical visualization of a recorded sequence.

The graphical visualization of a recorded sequence.

What are the next steps:

  • Include an online help
  • Internationalize the application
  • Configure and let the user access the update site
  • Enhance the graphical visualization and make it printable and exportable
  • Implement the possibility to configure and persist more than one event key configuration

July 19th, 2009

Behind the scenes - Using dynamic proxies

Most of the time, a developer has to integrate a new functionality into an existing system. The challenge is not only to develop the piece of code that solves the problem but also to integrate the result of your implementation without breaking the running system and reuse most of the modules that already exist. In this article I would like to give you an example of how dynamic proxies can be used to achieve an integrating task on the low level (i.e. on the code level). First let’s have a look on some theoretical aspects.

Dynamic Proxy is a well known design pattern often used to protect or control the access to an object instance. A proxy object implements the same interface (or set of interfaces) of the object you want to control the access of. Instead of using the object itself, the proxy is passed to the client code.

All method call invocations are delegated to the proxy instance. The proxy instance makes most of the time either a pre-processing, a post-processing, handle the method invocation itself or just delegate the execution to the real object. Attentive readers will notice that this sounds like the decorator pattern. But there is a slightly difference between the decorator and the proxy pattern. The proxy pattern do not encapsulates the target object, it only acts as a delegate. For more details please have a look at the excellent article on JavaWorld.

Since Java 1.3, implementing dynamic proxies has been largely simplified by the introduction of the Dynamic Proxy API. See the following API description for more details. As mentioned above, to use dynamic proxies, you have to implement the same interface as your target object. But what if the target object do not implement any interface? That is exactly where the cglib library comes to the rescue. It is a code generation library used to extend Java class and implements interfaces at runtime. A prominent framework that makes an extensive use of it is Spring.

I would like to illustrate the use of dynamic proxies and especially the use of the cglib library through a very basic example. Suppose your company spent a lot of money to acquire a printing framework you now want to embed in your brand new product. Your product has a client-server based architecture where data are stored on a database accessible through the server.

With the client, you can browse the content of the repository. Your customers now want to be able to print out the content of a container. The printing frameworks can only handle some kind of files types. Furthermore let say that this framework is continually being enhanced. Every new release support more files types. The only fact we know about the framework is that it uses file extensions to determine which file types can be proceeded. The code the printing frameworks uses (which in fact is not modifiable) look like in the snippet below:

package com.dmissoh.proxies;
import java.io.File;
import java.util.Collection;
import java.util.Iterator;
 * This is the class responsible for printing in a third party library.
 * In the real world, this class cannot be edited.
 * The logic use in this class is simple. The file name is used to decide if it should be printed or not.
 * Only files having the extension <strong>pdf</strong> will be proceeded. If this condition is fulfilled,
 * the <code>File.getAbsolutePath()</code> method is called to retrieve the full path, and print the file out.
 * P.S.: A file that is going to be printed should also be accessible on the disc.
 * @author Dimitri Missoh
public class ThirdPartyPrinter {
	public void printOutFiles(Collection files) {
		if (files != null) {
			for (Iterator iterator = files.iterator(); iterator.hasNext();) {
				File file = iterator.next();
				String fileName = file.getName();
				if (fileName.indexOf(".pdf") &gt; -1) {
					String path = file.getAbsolutePath();
					System.err.println("Print the file: " + path);

Since files are physically located on the back-end we don’t want to download them all before sending them to the printing framework. This do not make sense because we know that the printing framework can handle only a predefined set of file types. In addition we want to be careful with the available bandwidth.

In the current version we know that the printing framework can only handle PDF files.

The quick and dirty approach will be:

  • first retrieve the list of files name available in the container
  • filter out only those having the extension PDF
  • send another server request to download only the PDF files
  • finally send the downloaded files for printing.

Well, this may be an acceptable solution until we get the next release of the printing framework which now handles more file types. We will than have to change the client code again to filter out not the new set of files the printing framework can now handle.
The printing framework calls two methods:

  • File.getName() to check if the file can be printed and,
  • File.getAbsolutePath() just before it prints the file.

Since the printing framework uses the java.io.File, the idea is to use cglib to create a proxy for the File object. The job of this proxy will be to download the file every time the File.getAbsolutePath() is called (since this method is called only for those files).

P.S.: Why can’t we just use the Dynamic Proxy API Java provides out of the box? The response is trivial, the File object do not implements any interfaces.

So let see how the new implementation could look like:

The PrintClient simulates the client code that calls the printing framework. It instantiates the file proxies (LazyFileDownloaderProxy) and request the printing job.

package com.dmissoh.proxies;
import java.io.File;
import java.util.ArrayList;
import java.util.Collection;
import net.sf.cglib.proxy.Enhancer;
 * This class represents the client code, the one that calls
 * the third party library's API to print a given collection of files.
 * Instead of calling the third party's APi with a list of <code>File</code>,
 * a collection of <code>LazyFileDownloaderProxy</code> are passed as arguments.
 * This proxies intercept method calls and allow us to make some preprocessing.
 * @author Dimitri Missoh
public class PrintClient {
	 * The main method that calls methods in the third party library.
	 * @param args
	public static void main(String[] args) {
		Collection files = new ArrayList();
		File fileOne 	= (File) newInstance(File.class, "/home/docs/paper.txt");
		File fileTwo 	= (File) newInstance(File.class, "/home/docs/publication.pdf");
		File fileThree 	= (File) newInstance(File.class, "/home/docs/logo.gif");
		File fileFour 	= (File) newInstance(File.class, "/home/docs/book.pdf");
		// Print all pdf-Files by calling the API in the third party library
		ThirdPartyPrinter fileChecker = new ThirdPartyPrinter();
	 * Returns an proxy instance that encapsulate a <code>File</code> object.
	 * @param clazz the <code>Class</code> to create the proxy instance for.
	 * @param argument the arguments to passed to the constructor.
	 * @return a proxy instance of the class passed as argument.
	public static Object newInstance(Class clazz, Object argument) {
		try {
			Enhancer e = new Enhancer();
			e.setCallback(new LazyFileDownloaderProxy());
			Class[] argumentTypes = new Class[]{String.class};
			Object[] arguments = new Object[]{argument};
			return e.create(argumentTypes, arguments);
		} catch (Throwable e) {
			throw new Error(e.getMessage());

The LazyFileDownloaderProxy is the heart of our example. Method invocations done on the File object (through it proxy) are intercepted. If the called method is getAbsolutePath, the file will be first downloaded and the invocation is than delegated to the File object itself.

package com.dmissoh.proxies;
import java.io.File;
import java.lang.reflect.Method;
import net.sf.cglib.proxy.MethodInterceptor;
import net.sf.cglib.proxy.MethodProxy;
 * This class is used as proxy for a <code>File</code> object.
 * The aim of this class is to intercept method calls done on the File object
 * through this proxy.
 * This proxy class dowload the file just before the File.getAbsolutePath() is called,
 * and than delegate the processing to the corresponding method of the <code>File</code> object.
 * @author Dimitri Missoh
public class LazyFileDownloaderProxy implements MethodInterceptor {
	 * (non-Javadoc)
	 * @see net.sf.cglib.proxy.MethodInterceptor#intercept(java.lang.Object,
	 * java.lang.reflect.Method, java.lang.Object[],
	 * net.sf.cglib.proxy.MethodProxy)
	public Object intercept(Object obj, Method method, Object[] args,
			MethodProxy proxy) throws Throwable {
		Object returnValueFromSuper = null;
		String methodName = method.getName();
		File file = null;
		if ((obj instanceof File)) {
			file = (File) obj;
		// If the getAbsolutePath() method is called, download the file.
		if ("getAbsolutePath".equals(methodName)) {
			if (file != null) {
		// Than return the value as if it has been called on the corresponding method of the File class.
		try {
			returnValueFromSuper = proxy.invokeSuper(obj, args);
		} catch (Throwable t) {
			System.out.println("throw " + t);
			throw t.fillInStackTrace();
		return returnValueFromSuper;
	 * The dummy method called to download the file. This represent the time or resource
	 * consuming operation.
	 * @param file the file to download.
	private void downloadFile(File file) {
		for (int i = 0; i &lt; 3; i++) {
			try {
				System.out.println("Downloading file '" + file.getName()
						+ "' ..." + (i + 1) + " second(s)");
			} catch (InterruptedException e) {

P.S.: From the cglib website, I download the library file that contains all dependencies (cglib-nodep-2.2.jar).

The screenshot below shows the project structure:

The project structure

The project structure

The project structure

Source files to this article can be either downloaded from this Blog or are available through the SVN repository https://homeworks.googlecode.com/svn/trunk/.

Download Projects Files.

February 15th, 2009

Nuts and bolts of the UI development: GUI Test of SWT and Eclipse Applications

To be honest, I’m not the programmer I’ve dreamed to be, the one that has 100% of his code test covered. As a GUI developer I had an excuse in the past, namely that there are no acceptable GUI testing frameworks one can rely on (open source and suitable for eclipse RCP Application). I tried some of them but wasn’t very happy:

Until the day I’ve found the SWTBot library developed by Ketan Padegaonkar. This library still under development but can already be used to write professional functional test for SWT and eclipse based applications. The API is simple, intuitive but powerfull. This framework has such a success, that in the meantime there is a proposal to move it to the eclipse.org foundation.

This tutorial describes step by step how to configure your IDE to be able to test your first RCP application. I hope that this warm-up will encourage beginners to adopt, put into practice and understand the importance of GUI testing in their daily work.

So let’s start:

System requirement:

  • The Java JRE 5.0 is installed on my PC
  • and I’am using the Eclipse IDE for Plug-in developer (Ganymed - version 3.4 SR1)

Step 1 - Installing SWTBot

  • Start your eclipse IDE and choose [Help/Install New Software...]
  • Than click Add Site and enter the following URl for the updatesite: http://swtbot.sourceforge.net/download.html. Than [OK]. You can also download the plug-ins directly if you prefere. See the SWTBot webpage for more details.
  • Select “SWTBot Eclipse Feature” and “SWTBot SWT Feature” and install them (your probably need to restart the workbench).

Step 2 - Download the Apache commons collection library

Since SWTBot depends on this library, it should be dowloaded and added in the next steps to the classpath.

Step 3 - Create the RCP application under test

  • We use the Mail Sample delivered with the IDE as the project under test. To create this project simple choose [File/New/Project/Plug-in Project] and enter the name “com.dmissoh.rcp.mail” or any name of your choice.
  • Access the next wizard page by clicking on next. In the “Plug-in options” group check the options “Generate an activator….” and “This plug-in will make contribution to the UI“.  Then check the option yes that corresponds to the question “Would you like to create a rich client application?
  • Choose “RCP Mail Template” on the next wizard page, and terminate with [Finish].

Step 4 - Create the test plug-in

  • As described in step 3 create a new plug-in project using [File/New/Project/Plug-in Project]
  • Do not use any template for this project
  • Name it “com.dmissoh.rcp.mail.test
  • Use the context menu on this project and add a the new folder “lib” as shown in fig. 1
  • Use the context menu on this project and add a the new folder “config
  • In the ‘config’ folder create a new file named log4j.properties and fill it with the content of the snippet below:
    log4j.rootCategory=DEBUG, R, O
    # Stdout
    # File
    # Control the maximum log file size
    # Archive log files (one backup file here)
    log4j.appender.R.layout.ConversionPattern=[%d{ISO8601}]%5p%6.6r[%t]%x - %C.%M(%F:%L) - %m%n
    log4j.appender.O.layout.ConversionPattern=[%d{ISO8601}]%5p%6.6r[%t]%x - %C.%M(%F:%L) - %m%n
  • Copy the jar file “commons-collections-3.2.1.jar” you previously unzip in step 2 into this “lib” folder.
  • Go the the plugins folder of your eclipse IDE (e.g. under “C:\Programme\eclipse3.5\eclipse\plugins”), and copy the following jars into the “lib” folder: net.sf.swtbot.eclipse.finder_1.2.0.921.jar, net.sf.swtbot.eclipse.spy_1.2.0.921.jar, net.sf.swtbot.eclipse.ui_1.2.0.921.jar, net.sf.swtbot.finder_1.2.0.921.jar as shown in fig.1.
  • Double click on the file “META-INF/MANIFEST.MF” of the project “com.dmissoh.rcp.mail.test”, select the tab “runtime” and use the “Add…” button to add the five jar that we’ve copied into the lib folder of this project. At the end, it should look like on fig. 2.
  • We now need to add some dependencies to our test plug-in. Click on the MANIFEST.MF file located in the META-INF folder of the test plug-in org.dmissoh.rcp.mail.test and open the tab Dependencies. Use the Add button to add both org.apache.log4j (bundle-version=”1.2.13″) and org.junit (bundle-version=”3.8.2″) to the dependencies. Fig. 3 show how it should looks like.

P.S.: This is the quick and dirty way to add third party jars into your project. It is always better to add all the jar file your project depends on in a another plug-in, and add this library plug-in as a dependency to your main plug-in.

Figure 1 - Project structure in the eclipse IDE

Figure 2 - The classpath after jars have been added.

Figure 3 - Project Dependencies

Step 5 - Writing the test class

It is now the time to write the test case.

  • Use the context menu on the ’src’ folder of the ‘org.dmissoh.rcp.mail.test’ plug-in project to add the new package org.dmissoh.rcp.mail.test
  • In this package create a new class RcpMailTestCase and fill it with the snippet below. P.S.: This Test Case class should extends the SWTBotEclipseTestCase. As you can see, this test cases checks the some of the basic functionalities the mail RCP application contains like the tree viewer and the about dialog.

package org.dmissoh.rcp.mail.test;
import net.sf.swtbot.eclipse.finder.SWTBotEclipseTestCase;
 * A test case to run some basic unit tests on the Mail RCP sample.
 * @author Dimitri Missoh.
public class RcpMailTestCase extends SWTBotEclipseTestCase {
	 * Test the about dialog
	 * @throws Exception
	public void testAboutDialog() throws Exception {
		 * Check that we can open the about dialog,
		 * the plug-in details dialog and
		 * the configuration details dialog.
		 * */
		bot.menu("Help").menu("About RCP Product").click();
		bot.button("Plug-in Details").click();
		bot.button("Configuration Details").click();
	 * Test the dialog and the corresponding menu's command
	 * @throws Exception
	public void testDialog() throws Exception {
		 * Try to open the dialog using the menu.
		 * This is a way to make sure that this menu option is available.
		 * Also make sure that the dialog can be closed
		 * */
		bot.menu("File").menu("Open Message").click();
	 * Test the navigation tree
	 * @throws Exception
	public void testTree() throws Exception {
		 * Now we try to navigate the tree.
		 * Make sure that the first tree node has 3 children
		 * */
		assertEquals(1, bot.tree().getTreeItem("me@this.com").getNodes().size());
		assertEquals(3, bot.tree().getTreeItem("me@this.com").getNodes().size());
		 * Make sure that the second tree node has only one child
		 * */
		assertEquals(1, bot.tree().getTreeItem("other@aol.com").getNodes()
		assertEquals(1, bot.tree().getTreeItem("other@aol.com").getNodes()
	 * Test view related functions
	 * @throws Exception
	public void testView() throws Exception {
		 * Check that we have only two view opened on start:
		 * - the message view
		 * - the navigation view
		 * Than open one additional message view and check that we have one view more.
		 * At the end we close both message view and make sure that we have only one view left
		 * i.e. the navigation view.
		assertEquals(2, bot.views().size());
		bot.menu("File").menu("Open Another Message View").click();
		assertEquals(3, bot.views().size());
		assertEquals(1, bot.views().size());

Step 6 - Running the test

Running the SWT bot test is as simple as running a classic JUnit test. Expect that we have to set the path to the log4j.configuration file in the corresponding Debug Configuration Dialog.

  • Click right on the RcpMailTestCase class in the package explorer and select [Run As/SWTBot Test], which is a new entry that should appears if the SWTBot feature as been successfully installed as described in Step - 1.
  • The test run will failed because the the path to the Log4J configuration file is missing.
  • Select from the menu [Run/Debug Configurations...] to open the debug configuration dialog
  • Select the corresponding SWTBot test (I’v called it MailTest)
  • In the Test-Tab select JUnit 3
  • In the Main-Tab select org.dmissoh.rcp.mail.product under [Program to Run/Run a Product:]
  • In the Arguments-Tab add the following entry to VM Arguments as shown on fig. 4:

Figure 4 - Debug Configuration

If all test runs without failure you should see the pleasant JUnit green bar at the end.

For those who are interested in the use of JUnit in general for RCP and OSGi applications, the following blog entries can be useful:

In his article Running Unit Tests for RCP and OSGi Applications, Patrick describes how sets of tests across multiple plug-ins or fragments can be run without using test suites. In one of his previous articles (Testing Plug-ins with Fragments) he explains how fragments can be used to separate the test code from the business code.

Download Projects Files.