Aspect oriented programming with Java

A practical introduction

Writing software is a complex business - not only do you have to get the enterprise logic of the application correct, typically you also have to deal with multiple other concerns at the same time, such as "what should happen if something goes wrong", "how should I make sure we know what is happening during execution", "how to enforce security throughout my application" and in some languages "how do I handle memory" or "when should I free up memory", etc.

In Java, of course, we have already been able to move much of the responsibility, and thus the implementation of, memory manage and garbage collection into the Virtual machine. However, Java software still often needs to handle multiple concerns within the same body of code. A classic example is the use of user validation code and logging code within a Java class that performs some form of system behaviour (such as requesting a book from a library etc).

Such cross cutting concerns are one of the underlying motivators behind what is know as Aspect Oriented Programming (or AOP). The basic idea behind AOP is that each concern within an application should be implemented within its own independent module (or Aspect). Thus, a logging module only deals with logging and isn't tangled up with other business logic.

The Basic Concepts of AOP

Software development has progressed a long way in the last 20 or 30 years. Twenty years ago it was not uncommon to find assembler and high-level code mixed together in the same (pages long) source code listing. However, we have improved awareness of the benefits of highly cohesive, but loosely coupled code, we have accepted the need for modularity in our systems, and we have adopted (within Java at least) Object Orientation as a basic software engineering technique.

However, I can still find myself looking at a source code listing and having to try to pull out the basic business logic, from all the "stuff" that sits around it.

All this "stuff", such as calls to logging components, authentication checks, exception handling, transaction management, etc, is all very important within any large software system. However, it adds to the fog that can surround a potentially simple piece of business logic.

Interestingly, one of the compelling arguments for making techniques such as Automatic Garbage Collection and Memory Management mainstream was that it separated out the implementation detail of managing memory from the business logic required by an application. Mixing the two made software more difficult to read, understand, and maintain; by placing the memory management in the background, the core business logic was that much simpler. This is essentially the premise behind AOP.

Let's take logging as an example. It's quite possible to design and implement a logging subsystem (indeed many have done this for Java including the Apache Log4J Logging framework).

However, the problem is that such a subsystem just provides the ability to log; it says nothing about where and when you should log system behaviour. To do this you most go through your software system and add such logging statements to appropriate points within methods. The end result is that the user of the logger needs to know that it is available, what its API is and, of course, must decide where to place the logging statements.

In turn the pure business logic methods are now augmented by additional (non-business related) method calls. As this process may be repeated for numerous such subsystems, the initially clean code may now be far more complex. This, in extreme cases, may make it more difficult to understand the underlying, relatively simple, business logic.

Logging here is an example of a cross cutting concern. That is, it is an aspect of the systems behaviour that cuts across many other modules. AOP allows Logging to be implemented as a completely self-contained module that is dynamically linked with the initial business logic in such a way that the original source code is unchanged. The self-contained, or stand-alone modules, are referred to as Aspects within AOP.

AOP programs can achieve the linking of the Aspect with the pure business logic code in a number of ways. For example, a pre-processor could be used to produce a combined program that is then compiled to produce the runtime executable (this was the approach originally used by AspectJ back in 2001). Another approach is to provide some form of post compilation modification.

In Java';s case, this means modification of the byte codes generated for classes such that links to an appropriate Aspect are incorporated into the byte codes. Such byte code weavers can be deployed during the build process or, if the weave model is per-class, during class loading. AspectJ has evolved from providing per-class bytecode weaving in 2002 to advanced load-time integration form 2005. The final approach is to augment the underlying execution environment (in Java's case the JVM) so that it understands AOP language elements directly.

AspectJ for Java

AspectJ is currently the most complete implementation of an AOP language for Java. In practical terms, it is an extension to Java that treats AOP concepts as first-class elements of the language. It allows aspects to be implemented as part of a Java based application using familiar Eclipse based tools.

As AspectJ is an extension to Java, Java is the implementation language for the constructs that comprise an Aspect. That is, you use Java to implement whatever behaviour the Aspect should provide. A set of rules is then used to determine how to weave the aspect into the main body of your Java application. These rules are implemented by pointcuts, join points, and advice. A pointcut specifies what join points there are. In turn, a join point defines where in a Java programs' execution the aspect should be applied and advice is the implementation of what to do at that point.

The actual syntax of the AspectJ language is Java-like, details of which can be obtained from the AspectJ home page.

Next page: A simple example

Other stories you might like

  • Firefox kills another tracking cookie workaround
    URL query parameters won't work in version 102 of Mozilla's browser

    Firefox has been fighting the war on browser cookies for years, but its latest privacy feature goes well beyond mere cookie tracking to stop URL query parameters.

    HTML query parameters are the jumbled characters that appear after question marks in web addresses, like Sites such as Facebook and HubSpot use them to track users when links are clicked, and other websites like YouTube use them to enable certain site features too.

    On June 28, Firefox 102 released a feature that enables the browser to "mitigate query parameter tracking when navigating sites in ETP strict mode." ETP, or enhanced tracking protection, encompasses a variety of Firefox components that block social media trackers, cross-site tracking cookies, fingerprinting and cryptominers "without breaking site functionality," says Mozilla's ETP support page.

    Continue reading
  • Old school editor Vim hits version 9 with faster scripting language
    All of the famed user-friendliness and ease of use, but 'drastically' better performance

    Old school editor fans, rejoice: some two and a half years after version 8.2, Vim 9 is here with a much faster scripting language.

    Vim 9 has only a single big new feature: a new scripting language, Vim9script. The goal is to "drastically" improve the performance of Vim scripts, while also bringing the scripting language more into line with widely used languages such as JavaScript, TypeScript, and Java.

    The existing scripting language, Vimscript, remains and will still work. Only scripts beginning with the line vim9script will be handled differently. The syntax changes are relatively modest; the important differences are in things like local versus global variables and functions, and that functions defined with :def will be compiled before they are run. This allows many errors to be caught in advance, but more significantly, compiled functions execute from 10× to 1000× faster.

    Continue reading
  • Iceotope: No need to switch servers to swap air-cooled for liquid-cooled
    Standard datacenter kit just needs a few tweaks, like pulling off the fans

    Liquid cooling specialist Iceotope claims its latest system allows customers to easily convert existing air-cooled servers to use its liquid cooling with just a few minor modifications.

    Iceotope’s Ku:l Data Center chassis-level cooling technology has been developed in partnership with Intel and HPE, the company said, when it debuted the tech this week at HPE’s Discover 2022 conference in Las Vegas. The companies claim it delivers energy savings and a boost in performance.

    According to Iceotope, the sealed liquid-cooled chassis enclosure used with Ku:l Data Center allows users to convert off-the-shelf air-cooled servers to liquid-cooled systems with a few small modifications, such as removing the fans.

    Continue reading
  • Gartner predicts 9.5% drop in PC shipments
    Stark contrast to 11 percent increase year-over-year in 2021 shipments

    The party is over for PC makers as figures from Gartner suggest the market is on course for a breathtaking decline this year.

    According to the analysts, worldwide PC shipments will decline by 9.5 percent, with consumer demand leading the way – a 13.5 percent drop is forecast, far greater than business PC demand, which is expected to drop by 7.2 percent year on year.

    The PC market in the EMEA region is forecast to fare even worse, with a 14 percent decline on the cards for 2022. Gartner pointed the finger of blame at uncertainty caused by conflicts, price increases and simple unavailability of products. Lockdowns in China were also blamed for an impact in consumer demand.

    Continue reading

Biting the hand that feeds IT © 1998–2022