The Command Pattern is well-know pattern in the OO community. Originally described in the Gang of Four book there have been multiple variants over time (e.g. http://www.javaworld.com/javaworld/javatips/jw-javatip68.html). The main characteristics of the Command pattern are:

• separates the Client of a function from the Receiver through Commands. This separation provides the flexibility to extend independently the client and the receiver;
• the Command is a first class entity that can be manipulated outside the client or receiver. This allows to create new commands from the existing ones through inheritance, group multiple commands in one and add transaction capabilities. The Command is a reification of the method invocation by the client on the receiver.

The original command pattern is powerful in itself, but working with it in multiple projects I found some limitations:

• the Command object knows (i.e. is coupled with) the Receiver in order to invoke the method. That means that the Client, which builds the Commands is also aware of the Receiver (even if not all the details). This is against the original intent of the pattern which is to decouple the client from the receiver;
• in most cases the Client is interested in the results of executing a Command. Only rarely a client has a “send-and-forget” behaviour. There are ways to pass back the results to the client for example by having a “shared” context between  the client and the receiver. This solution creates a hidden dependency. A better option is for the client to register for command execution updates through the Command;
• often a Command invokes multiple Receivers in the same execution.

The article is about extensions to the Command Pattern to avoid these limitations.

(Continue reading …)

A few months ago I wrote an article about using Ivy to jump-start new Java applications. Since then I have used Ivy in all the new components which often have dependencies between themselves or third-party libraries sometimes open source, sometimes proprietary. This article is about new insights from this experience and the more general issue of application modularization.

Application modularization is a hot topic in the Java community. A concise and good article by Alex Blewitt is: Modular Java: What Is It?. It is easy to see the dependencies being a problem in large applications, but it affects small/medium scale applications as well. In these days it is easy to create a component/application that depends on a dozen of external libraries. Modules can depend on each other at compile-time and runtime. For compile-time dependencies there is no standard specification, instead ad-hoc formats have been defined by development tools: POM for Maven and Ivy files for Ivy. For run-time dependencies the current standard is OSGi implemented by the major J2EE application containers.

It is easy to see how a development team can be easily confused and frustrated by the topic of modularization. On one hand this is a common issue: new components are build and new versions are released by other teams and external parties. Compile-time dependencies are managed inside build scripts, and hard to maintain. For run-time dependencies, the standards (OSGi) and tools (Eclipse, bnd) are too complex to the point where only the tool providers are able to use them.

For the people who want to go beyond manually maintained classpath entries, I am suggesting to a combination of Ivy and jar MANIFEST files.

(Continue reading …)