Aspect Oriented Programming (AOP): Using AspectJ to implement and enforce coding standards

Introduction

Aspect-oriented programming is a relatively new concept with the purpose of lowering complexity inherent to software development.  Essentially, AOP "captures" multi-class interactions scattered throughout code (a.k.a. cross-cutting concerns) and encapsulates them into a single, centralized, class-like unit called an "aspect".  For more details on AOP, see the Resources section below.

An additional "tool" to help reduce program complexity is a uniform coding standard.  A good coding standard goes a long way in encouraging coding best practices: it increases code readability by promoting consistency, and, it allows peers to focus on class design and algorithms rather than mundane details such as whitespace formatting during code reviews.

One of the downsides to coding standards and reviews is delayed feedback - sometimes non-trivial changes are needed in code that has been updated between the time the review was scheduled and performed.  Knowing that a change costs less in the long run is a strong motivator to determine changes as soon as possible.  Another downside is that developers are sometimes resistant to, as well as, forgetful of the standards - especially when a deadline is hanging over their heads.  The optimal solution is to compel developers to follow standards during compilation and unit testing.

Aspects can enforce or implement standards two ways:  detecting static program structure at compile-time and dynamically detecting program state at run-time.  Specifically, compile-time aspects can detect inappropriate program structure and then emit a compiler message.  Run-time aspects, on the other hand, can detect interactive, conditional behavior and then augment or replace the programmer-defined behavior with the standard-defined behavior.

Examples: Compile-Time Coding Standards

As objects become increasingly complex through their lifetime, changing a single member variable may require updating another variable or interacting with another class.  Coders are sometimes unaware of these obfuscated constraints due to lack of documentation and convoluted coding.  Forcing programmers to use setter methods provides a single point of entry to update state rather than having it scattered and/or (incorrectly) copied throughout the class.  The following pointcut and advice enforces setter methods:

pointcut directMemberAssignment():
	set(* *.*) && !withincode(* set*(..)) && 
	!withincode(*.new(..));

declare error: directMemberAssignment():
	"Coding standards require the use of a setter for all " + 
	"member variable assignments, even within the class itself.";

Another difficult situation occurs when client code has not been insulated through a layer of indirection from low level libraries.  Changing design decisions after construction has started creates hard-to-find bugs.  Sometimes these changes are the result of accommodating a maturing library, other times it is the result of needing to completely replace an inadequate library.  Regardless, programmers should be forced through a single point of entry for things such as persistence or security so that side-effects can be minimized.  The following code from the AspectJ Programmer's Guide demonstrates how to enforce this standard:

pointcut restrictedCall():
	call(* java.sql.*.*(..)) || call(java.sql.*.new(..));

pointcut illegalSource():
	within(com.foo..*) && !within(com.foo.sqlAccess.*);

declare error: restrictedCall() && illegalSource():
	"java.sql package can only be accessed from com.foo.sqlAccess";

Examples: Run-Time Coding Standards

One particularly nasty type of bug to track down occurs when programmers use the "on error condition, return null from method" anti-pattern.  The reason this is an anti-pattern is two-fold: all calls to the method that are not wrapped by error handling code will cause a latent NullPointerException, and, the error handling code must be found and updated manually everywhere it is used.  The preferred technique is to have the method throw an exception with as much context as possible to describe the error condition.  To avoid copying exception handling code everywhere the method is called, an aspect can be written that will consistently handle the error.  Here is a snippet which detects the anti-pattern and outputs a message to the error console:

//The first primitive pointcut matches all calls,
//The second avoids those that have a void return type.
pointcut methodsThatReturnObjects():
	call(* *.*(..)) && !call(void *.*(..));

Object around(): methodsThatReturnObjects()
{
	Object lRetVal = proceed();
	if(lRetVal == null)
	{
		System.err.println(
			"Detected null return value after calling " + 
			thisJoinPoint.getSignature().toShortString() + 
			" in file " + 
			thisJoinPoint.getSourceLocation().getFileName() +
			" at line " + 
			thisJoinPoint.getSourceLocation().getLine()
			);
	}
	return lRetVal;
}

The final example coding standard is more related to debugging convenience and auditing rather than preventing poor programming practices.  In particular, distributed applications often run as a child process under a J2EE application server.  Based on the specific situation and application server, the application may not have access to the console for message display.  Also, these applications are running on multiple machines which can make debugging very difficult.  With these considerations, using a logging package is preferred to using System.out or System.err.

This example takes the concepts presented earlier and extends them by allowing a programmer to "opt-in" to aspect logging and use the features of the java.util.logging package.  To achieve this, an application must implement the ILoggable tag interface.  The aspect then uses static introduction to add methods and member variables to the implementing class for full access to logging.  The following snippet initializes logging:

private static Logger fLogger;

//Static introduction!
private static Logger ILoggable.fLogger;

pointcut initLogger():
  execution(*.new(..)) && !within(ForceLogging) && 
  !within(lib.aspects..*) && !within(ILoggable);

Object around(): initLogger()
  {
    //If the logger is not initialized, do it here.
    if(fLogger == null)
    {
      //Factory the logger based on the FQN of the object being 
      //instantiated.
      System.out.println("Creating a default logger named \"" +
        thisJoinPointStaticPart.getSignature().getDeclaringType().getName() + 
        "\"");

      /* The next line invokes advice that sets ForceLogging.fLogger 
       * to the same value.  This approach has been taken so that 
       * the Logger is easily used by both ForceLogging for 
       * intercepting System.out and System.err and for ILoggable 
       * default behavior.
       */
      ILoggable.setLogger(
        Logger.getLogger(
          thisJoinPointStaticPart.getSignature().getDeclaringType().getName()));
      try
      {
        String lUserDir = System.getProperty("user.dir");
        String lPathSep = System.getProperty("file.separator");
        System.out.println("File logging defaulting to <user.dir>" + 
          lPathSep + "<fully-qualified-class-name>.log:\n\t" + 
          lUserDir + lPathSep +
          thisJoinPointStaticPart.getSignature().getDeclaringType().getName());
        Handler lHandler =
          new FileHandler(
          lUserDir + lPathSep +
          thisJoinPointStaticPart.getSignature().getDeclaringType().getName() +
          ".log");
        fLogger.addHandler(lHandler);
      }
      catch(Exception e)
      {
        /* This is not the preferred way to notify a user of 
         * failing to create the handler because the preferred way 
         * is to use the handler that was supposed to be created!
         * However, this is only a minor error, so swallow the 
         * exception so that the application can continue.
         */
        e.printStackTrace();
      }
    }
    Object o = proceed();

    /* The log level is defaulted to the value set in 
     * ${java.home}/lib/logging.properties.
     *
     * The ConsoleHandler is the default Handler and is automatically 
     * added to the "parent" logger of all loggers.  Remove it from the 
     * logging.properties file if you don't want this behavior.
     */

    return o;
  }

//Static Introduction! -- also conforms to the "setter" coding standard.
public static void ILoggable.initLogging(Logger pLogger, Handler pHandler)
{
	setLogger(pLogger);
}

//Pointcut that joins on the setLogger() method
//that was statically introduced in this aspect!
pointcut setILoggableLogger(Logger pLogger):
	call(void ILoggable.setLogger(Logger)) && args(pLogger);

before (Logger pLogger): setILoggableLogger(pLogger)
{
	//This sets the Logger for the ForceLogging aspect.
	setLogger(pLogger);
}

//Pointcut that joins on the initLogging() method
//that was statically introduced in this aspect!
pointcut initILoggableLogger(Logger pLogger, Handler pHandler):
	call(void ILoggable.initLogging(Logger, Handler)) && 
	args(pLogger, pHandler);
		
before(Logger pLogger, Handler pHandler): initILoggableLogger(pLogger, pHandler)
{
	setLogger(pLogger);
	fLogger.addHandler(pHandler);
}

Please see ForceLogging.java aspect to see the more detailed Javadoc for these pointcuts and their related advice.  TestCodingStandards shows how to opt-in to logging and demonstrates how the EnforceCodingStandards aspect works.

Conclusion

Coding standards are a critical tool to ensure that programmers follow coding best-practices.  They do this by guaranteeing consistency and allowing peers to focus on more pertinent issues such as class structure, implementation, and purpose.  Aspects are a very handy technology to give programmers more immediate, uniform and ego-less feedback than peer code reviews.