To add the Maven dependency:

To use it:

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.

I assume that you install the last Eclipse release (Galileo), if you don’t, any older release will do it.

P.S.: You need the Eclipse for RCP/Plug-in Developers distribution of the Eclipse IDE.

So let’s go:

I - Create the Mail Demo plug-in

1) Choose File>New and select Plug-in project from the category Plug-in development. Go to the next wizard page by clicking on Next .

2) Enter e.g. ‘com.dmissoh.rcp.mail’ for the field Project Name then Next.

3) Select ‘Yes‘ for the option ‘Would you like the create a rich client application?‘, then click on Next to access the next wizard page.

4) Select the template ‘RCP Mail Template‘ then click on Next and Finish. You are now done for the first part. Eclipse should now shows the Manifest Editor that show details to the new plug-in and application can now be started (Using e.g. the link ‘Launch an Eclipse application‘ available in the ‘Testing‘ session of the manifest editor).

Start the Mail Demo RCP using the manifest editor.

II - Add a product configuration

1) Select the project your previously created in hte package explorer and then File > New > Other > Plug-in Development > Product Configuration then click on Next.

2) Enter e.g. ‘mail.product‘ for the field ‘File name‘. Under ‘Initialize the file content‘ the option ‘Use an existing product‘ should be selected and set to ‘com.dmissoh.rcp.mail‘ (which corresponds to the name you give you plug-in in step I/2). If it is not the case, just complete it manually. At the end of this procedure, eclipse automatically opens the product description file ‘mail.product’ in the manifest editor. This new editor provides a handy way to start the RCP application (similar to the step I/4) and most important to export this application.

3) To export the Mail application, just click on ‘Eclipse Product Export wizard‘, gives an export destination (e.g. the directory in which the application should be exported, you can e.g. create a folder on the Desktop for it) and click on Finish.

4) After some seconds, you will find the exported product in the folder you gives above. In the folder you give above, go to the underlying directory ‘eclipse‘ which should contains the file ‘eclipse.exe‘. This is the executable file to start the RCP mail demo.

Export the RCP application using the product configuration.

That it’s.

Note: I use e.g. this Mail Demo every time a have to develop an RCP application from scratch.

III - Outline

The next step will be to explore all of the possibilities Eclipse provides out of the box to develop RCP applications. Here are two excellent articles that address this topics:

• http://www.vogella.de/articles/RichClientPlatform/article.html
• http://www.ibm.com/developerworks/library/os-eclipse-brand/index.html

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.

Application’s Quick Help

Sequence recorded with the workbench.

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

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");
 
		files.add(fileOne);
		files.add(fileTwo);
		files.add(fileThree);
		files.add(fileFour);
 
		// Print all pdf-Files by calling the API in the third party library
		ThirdPartyPrinter fileChecker = new ThirdPartyPrinter();
		fileChecker.printOutFiles(files);
	}
 
	/**
	 * 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.
	 */
	@SuppressWarnings("unchecked")
	public static Object newInstance(Class clazz, Object argument) {
		try {
			Enhancer e = new Enhancer();
			e.setSuperclass(clazz);
			e.setCallback(new LazyFileDownloaderProxy());
			Class[] argumentTypes = new Class[]{String.class};
			Object[] arguments = new Object[]{argument};
			return e.create(argumentTypes, arguments);
		} catch (Throwable e) {
			e.printStackTrace();
			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)
	 */
	@Override
	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) {
				downloadFile(file);
			}
		}
 
		// 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);
			System.out.println();
			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 {
				Thread.sleep(1000);
				System.out.println("Downloading file '" + file.getName()
						+ "' ..." + (i + 1) + " second(s)");
			} catch (InterruptedException e) {
				e.printStackTrace();
			}
		}
	}
}

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

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.