Although these ideas may apply to a lot of different programming languages I chose to give examples written in Java, PHP or Python. There should be no problem to translate this into other, similar languages.

Indentation hell

A lot of years ago I read a text file describing the preferred coding style for the Linux kernel: it said that you’re screwed anyway if you need more than three levels of indentation. This stems from hackers using a screen resolution that allows a certain number of characters only. Writing code that uses a lot of nested statements causes the problem that you can’t read everything on a 80×25 terminal; wrapping lines may make things worse.

Back then the solution was to either increase the screen’s resolution or write clean code. Even today the latter is a good idea not only when writing code but maybe configuration files in general. Imagine a sysadmin in the server room with an old monitor only – he’ll thank you that you formatted the comments with a text width of 80 characters or less.

Let’s have a look at an example like the following. You’ll notice that I’ve use four levels of indentation: a for loop, an if statement, another for loop and another if statement.

for (int i = 0; i < x; i++) {
  if (i == y) {
    for (int j = 0; j < z; j++) {
      if (j == a) {
        // do something special
        // ...
      }
    }
  }
}

We can spot this pattern by looking at it’s tail: a lot of closing curly brackets. Refactoring this snippet consists of splitting the code into various functions and calling them at the right time. One solution might look like so:

public void a() {
  for (int i = 0; i < x; i++) {
    if (i == y) b();
  }
}
 
public void b() {
  for (int j = 0; j < z; j++) {
    if (j == a) do_something_special();
  }
}
 
public void do_something_special() {
  // do something special
  // ...
}

Now, the code is much easier to read and unit testing it will be more fun too. Don’t be afraid of adding extra functions into your program when you could write it all into one method/function. The latter is harder to maintain and rest assured that more method/function calls won’t add a serious performance penalty to your application in any way.

Inverting

It’s likely that you’ve seen a method that starts with an if statement, almost all the method’s code is inside that statement and at the end of the method you find the else block with only one statement in it, maybe some error handling code.

Instead of writing if statements that span multiple pages and contain lots and lots of code the following technique allows you to have the if statement on one line. As discussed above this avoids an unnecessary level of indentation as well.

Let’s have a look at an example: a simple method containing an if statement with another if statement which holds the real code of the method.

function doIt() {
  if (something == true) {
    if (something_else == true) {
      # do something...
      # ...
    }
  } else {
    throw new Exception();
  }
}

Simply by inverting the if statements we can write them on one line, producing the following, much cleaner code:

function doIt() {
  if (something == false) throw new Exception();
  if (something_else == false) return;
  # do something...
  # ...
}

Again, not just the statement but the whole method is easier to read. If you’re checking preconditions, this is the way to go. This also prevents the indentation hell mentioned above.

Splitting

Speaking of checks for the preconditions of certain methods, one might tend to put all checks into one single if statement. This may save you from e.g. writing code to throw an exception more than once but may result in a hard to understand if statement.

I recommend writing if statements that test only one or two conditions. Have a look at the following code which contains a giant if statement.

def method(a, b, c):
  if a <= 10 or a >= 20 or \
     b == False or \
     c == 'unknown':
    raise SomeException('Invalid arguments')
  # do something...
  # ...

We could argue that the code is pretty clean and easy to understand. True in this case, but the semantics aren’t obvious. What about introducing two more methods and raising more specific exceptions? Would result in this:

def method(a, b, c):
  if not inRange(a, 10, 20):
    raise SomeException('Argument a is out of bounds')
  if not isValid(b) or not isValid(c):
    raise SomeException('Argument b or c are invalid')
  # do something...
  # ...
 
def inRange(a, start, end):
  return a >= start and a <= end
 
def isValid(a):
  return not ( a == False or a == 'unknown' )

This may bloat your code a little bit but helps you reading the code almost like a sentence. Splitting one large if statement into smaller ones may result in sensible error messages too. And the introduction of small helper methods makes unit testing fun again.

Sorting

If you’re using the previous technique – splitting a single if statement into smaller, more concise portions – you should consider the order of the if statements. Let’s think about a simple example: in a recent post I tried finding occurrences of Friday the 13th dates by iterating over a given time span. The method looked like so:

while (/* ... */) {
    date = date.plusDays(1);
 
    if (date.getDayOfMonth() != 13) continue;
    if (date.getDayOfWeek() != DateTimeConstants.FRIDAY) continue;
 
    // ...
}

The two if statements test whether the current day is a Friday the 13th date. First checking whether the current day is the 13th day of a month speeds things up a little bit because we’ll only check whether this day happens to be a friday – the other way around would be more expensive in terms of performance.

This technique also applies when your if statements call expensive methods to test a certain condition. You may want to call the ones with the least overhead first thus reducing the time spent in your if statements.

Conclusion

In this post I presented some simple solutions that should help you writing cleaner, better code regarding if statements. Following these rules will make your code much easier to read and to maintain. Just give it a try and you’ll definitely notice the positive difference.

Sure, I haven’t given any references to real projects helping you to verify that the examples given in this post exist in real projects. I think searching in real projects for code like the above shouldn’t be much of a problem. And I’m pretty sure you’ll agree on this.

Since there wasn’t a German translation for it I created one and the author, Matteo Lucarelli, integrated it into a new release. If you’re from Germany and don’t speak English you may want to give this software a shot.

• using an Iterable
• toCharArray()
• charAt()
• calling charAt() on a CharSequence

You can download the Eclipse project as a tar or zip or browse the code online here; have a look at the StringIteratorTest class first.

Results

Without further ado here are the results:

Conclusion

If speed is what you want you shouldn’t use Iterators but one of the other solutions instead. On the other hand if you just like to play with Iterators and classes that implement Iterable you may want to choose the slower solution.

You can download the Eclipse project as a tar or zip file or view the code online here.

Implementation

If you don’t know how dynamic proxy classes work here’s a short overview. Let’s say you want to do some extra work if the methods foo and bar from the class Tee are called. You would extract the methods into an interface and let Tee implement this interface.

Next, you’d implement a factory that produces a proxy instance for Tee with a custom InvocationHandler. This handler would have a look at the method’s name and check whether it’s foo or bar: you can now implement any extra actions in this handler.

You can also examine the annotations of the invoked method and that’s what I did: if the method has got the @Cachable annotation we’ll utilize a cache. But how do we know whether we can safely return an object from the cache?

Constructing a unique method identifier

This is crucial since we don’t want to return the same result from the cache if the method was called with different parameters. So we’ll have to add the values of the parameters to a identifier like so:

"package-name" + "class-name" + "method-name" + "param1-param2-[...]"

This way we’ll create a unique entry in the cache for different method calls.

How to

All we have to do is to add @Cachable to some methods:

public interface Foo {
  @Cachable
  public SomeObject foo(int param);
  @Cachable
  public AnotherObject bar(int param1, long param2);
}

Once we’ve done that we can use the factory to produce a new proxy instance with our custom InvocationHandler. The handler will use the cache, i.e. the method calls will return faster.

Conclusion

In this post I presented a simple solution for a cache that may speed up method calls. Although I recommend using AspectJ for this kind of job you can use dynamic proxy instances if your environment (in most cases read: your project leader) doesn’t permit you to use AspectJ.

You can download the Eclipse project as a tar or zip file or browse the code online here.

Implementing the aspect

I decided to use an annotation and an aspect with a pointcut that matches this annotation. All I had to do was to annotate the methods that should be cached.

Here’s the very generic version of a pointcut that matches the execution of all methods annotated with @Cachable:

@Pointcut("execution(@Cachable * *.*(..))")
private void cache() {}

The logic is this simple:

@Around("cache()")
public Object aroundProfileMethods(ProceedingJoinPoint thisJoinPoint) {
  // construct genericIdentifier
  Object obj = cache.get(genericIdentifier);
  if (obj == null) {
    obj = thisJoinPoint.proceed();
    cache.put(genericIdentifier, obj);
  }
  return obj;
}

Everytime a cachable method is executed we’ll first have a look at the cache. If there’s a cache hit we’ll immediately return the object. If there’s no such object in the cache, we’ll call the cachable method, put the returned object in the cache and finally return the object.

The genericIdentifier is a string consisting of the package-, class- and method-name and the supplied arguments. For a method named foo from a class bar inside a package called baz this might result in:

"baz.bar.foo-Integer-42"

The method foo takes one argument and at the time of this execution it was 42. This way we’ll only return objects from the cache if this generic identifier matches.

Using the aspect

All we have to do is to use the @Cachable annotation. Have a look at it:

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Cachable {}

It can be used with any method that returns something:

@Cachable
public BigObject getObject(final int param) {
  return new BigObject(param);
}

The first time this method is called we’ll store the object in the cache. If it’s called again with the same parameter we’ll return the object from the cache.

Conclusion

Implementing a cache is simple and so is using it with AspectJ. I presented a straightforward way to speed up any application that deals with big objects which take a long time to load. All you have to do is to use the @Cachable annotation along with the aspect. Implementing another cache in the aspect should be simple, too.

You can download the Eclipse project as tar or zip or browse the code online here.

Basic operations

The cache supports these basic operations: you can put and get objects. If you put an object you can specify a time in seconds – after this time period the object will be remove from the cache.

Getting an object from the cache is simple too and you’ve also got the possibility to specify the type of the object you’re retrieving from the cache – this adds some type safety.

Have a look at this sample code:

SimpleCache<Integer> intCache = new SimpleCache<Integer>();
intCache.put("one", 1);
assertEquals(new Integer(1), intCache.get("one"));

This creates a SimpleCache that holds objects derived from Integer. Since you parameterized this cache with Integer you’ll only be able to put and get integers.

If you want to save all different kinds of objects in the cache that’s no problem at all. If you do this you can use the convenience method get which performs a cast for you. Have a look at this example:

SimpleCache cache = new SimpleCache();
cache.put("one", 1);
cache.put("str", "Some string");
assertEquals(new Integer(1), cache.get("one", Integer.class));
assertEquals("Some string", cache.get("str", String.class));

However, I think it’s better to create several instances of SimpleCache that stores objects of a specific type.

Removing expired objects

Once an object is expired we want to remove it from the cache. The SimpleCache class supports two ways of removing old objects:

1. if the get method is called we’ll check whether the object that’s about to be returned is expired. If that’s the case we’ll remove it from the cache.
2. a thread that runs periodically removes expired objects from the cache.

Both features reside in implementations of Runnable so they can be executed in separate threads. This way the basic operations will not be slowed down by this kind of housekeeping.

With Java 5 it’s easy to schedule recurring tasks with the Executors class. To remove expired objects from the cache we can use this code:

Runnable cleaner = new Runnable() {
  public void run() { /* remove expired objects here */ }
};
Executors.newScheduledThreadPool(1)
         .scheduleWithFixedDelay(cleaner, 0, 30, TimeUnit.SECONDS);

Conclusion

I presented a very simple cache written in Java that stores objects of any kind. It’s configurable, type safe and easy to use; it should be pretty easy to integrate this cache into an existing project.

I’ve tried to keep the cache fast: certain tasks will be executed in threads to speed things up. But don’t worry because the threads are easy to maintain and to understand.

Installation

The installation for Lambda Probe is pretty easy: download probe.war and copy it to $CATALINA_HOME/webapps/.

Once you’ve done that make sure that the user tomcat has the role manager. Have a look at your tomcat-users.xml file:

<tomcat-users>
  <role rolename="manager"/>
  <role rolename="poweruser"/>
  <role rolename="poweruserplus"/>
  <role rolename="probeuser"/>
  <user name="tomcat" password="tomcat" roles="manager" />
</tomcat-users>

You can use the other roles to configure access to Lambda Probe. Have a look at this page if you want to do that.

If you want to have a look at the memory graphs and everything JMX related you’ll have to enable JMX Remote. This comes down to these lines:

export CATALINA_OPTS="-Dcom.sun.management.jmxremote 
       -Dcom.sun.management.jmxremote.port=9080 
       -Dcom.sun.management.jmxremote.ssl=false 
       -Dcom.sun.management.jmxremote.authenticate=false"

That’s it. Now you’re ready to use Lambda Probe.

Conclusion

If you want to monitor and administer web applications inside Apache Tomcat, Lambda Probe seems to be a very nice solution. I recommend to definitely give it a try.

Update: There’s a pretty active fork of Lambda Probe called PSI Probe around. I recommend using this instead.

Depending on the version of Velocity you’re using you’ll have to implement either LogSystem or LogChute.

Howto

If you’re using Velocity 1.4 or older use this class:

import org.apache.velocity.runtime.RuntimeServices;
import org.apache.velocity.runtime.log.LogSystem;
 
public class VelocityNoOutputLogger implements LogSystem {
  public void init(RuntimeServices arg0) throws Exception {}
  public void logVelocityMessage(int arg0, String arg1) {}
}

If you’re using Velocity 1.5 or newer use this class:

import org.apache.velocity.runtime.RuntimeServices;
import org.apache.velocity.runtime.log.LogChute;
 
public class VelocityNoOutputLogger implements LogChute {
  public void init(RuntimeServices arg0) throws Exception {}
  public boolean isLevelEnabled(int arg0) { return false; }
  public void log(int arg0, String arg1, Throwable arg2) {}
  public void log(int arg0, String arg1) {}
}

Finally you’ll have to tell Velocity about the new logger:

Velocity.setProperty(Velocity.RUNTIME_LOG_LOGSYSTEM,
                     new VelocityNoOutputLogger());
Velocity.init();

Conclusion

We’ve implemented a simple way to suppress logging altogether. This comes in handy sometimes, so decide whether you want to use it too.

• Commons BeanUtils
• Spring BeanUtils
• Dozer

Furthermore I used my own implementation and an implementation that’s hardcoded by hand.

The Eclipse project with the sample code for this post can be downloaded as tar.gz or zip or can be viewed online here.

Testing

The performance test creates two beans: one is filled and the other gets filled; this is done over and over again in a big for loop. I coded a by hand implementation as a reference to check whether the process of creating all these new objects is slow. This implementation copies the properties from one bean to the other like so:

bean2.setFoo(bean1.getFoo());
bean2.setBar(bean1.getBar());
bean2.setTee(bean1.getTee());

All the other frameworks had to do the same thing. Have a look at the results (note that I set the y-axis to logarithmic scale):

Obviously there’s no problem with all the created objects: the by hand implementation just consists of the created objects and some method calls to copy the properties. This seems to be pretty fast compared to the other solutions.

Let us have a look at a comparison between the by hand implementation and the frameworks when they have to fill 100k objects:

For example: the by hand implementation beats Dozer by a factor of 970, i.e. it’s 970 times faster.

Conclusion

The results can be explained with the different richness of features. My Introspector and the implementation from the Springframework have very few features and are pretty fast. The Commons BeanUtils implementation has a lot of features (e.g. all this DynaBean stuff). And finally Dozer: I haven’t looked at the code yet, but it seems to be very powerful.

So once more it’s a trade-off between speed and features. Obviously you can’t have both so decide which one your application needs.

The Eclipse project with the sample code for this post can be downloaded as tar.gz or zip; make sure to install the AspectJ Development Tools. You can browse the code online here.

Classic singleton pattern

The traditional way to implement a singleton consists of a private constructor, a static final field that holds the instance of the class and a getInstance method that returns this instance. In Java this looks like this:

public class Singleton {
  private static final Singleton singleton = new Singleton();
 
  private Singleton() {}
 
  public static Singleton getInstance() {
    return singleton;
  }
}

This gets really annoying if you’ve got this code more than once in your application. So lets have a look at an aspect that resembles this functionality.

Implementing the aspect

If you’ve got more than one singleton in your application you may think of a singleton as a crosscutting concern. Consequently, you’ll write an aspect that intercepts calls to the constructor of the singleton class and instead of creating a new instance every time you’ll return the instance that was created at the very fist call to the constructor.

The logic for this idea can be expressed with the following code fragment:

Map<Class<?>, Object> singletons;
...
Class<?> singletonClass = joinPoint.getSignature().getDeclaringType();
Object singletonObject = this.singletons.get(singletonClass);
if (singletonObject == null) {
  singletonObject = joinPoint.proceed();
  this.singletons.put(singletonClass, singletonObject);
}
return singletonObject;

We have a map that holds references to all instances of our singleton classes. The method that intercepts the calls to the constructor of a given class stores a reference to the created instance in the map and returns that instance on the following calls to the constructor of the same class.

So, you can do the following in the code and will get references to the same instance of the class:

Singleton s1 = new Singleton();
Singleton s2 = new Singleton();
// s1 == s2

All that’s left to do, is to define a pointcut and to remove the boilerplate code from the singleton class. A pointcut can look like this:

@Pointcut("call(*.SingletonAop.new(..))")
protected void singletons() {}

Conclusion

We implemented a solution for the singleton pattern with AspectJ 5. The used approach caches the instances of the singleton classes and returns the cached ones once the constructor has been called for the first time. Note: to simplify matters we left out thread safety.

Although this solution is somehow elegant and may be useful to clean up some code in a legacy system, we should consider the following points:

Can we use a dependency injection framework?

Spring uses singletons by default and with Guice you can mark singletons with the @Singleton annotation. So, we might want to choose one of these frameworks instead of implementing this functionality on our own.

Java skill of the team?

The presented implementation should be well documented, because nothing would be more irritating than a novice developer in your team who doesn’t know about this magic behind the scenes and relies on different instances of the singleton class (“I thought new would be doing…”).

There are other solutions available to this problem. So, I wouldn’t recommend to implement this kind of caching with AspectJ.