© Copyright 2006 Contributors. All rights reserved.

# AspectJ 5 v1.5.3 Readme

This release includes a number of bug fixes and enhancements (over 80). The full list of resolved issues can be found with this bugzilla query.

Notable changes since the 1.5.2 release include:

## Pipeline compilation - 146781

Until this release, the memory profile for AspectJ looked like this (time is along the X axis, memory usage is the Y axis)

`

         /\_
        /   \_
       /      \_
      /         \_
     /            \_
    /               \

`

The first phase (as we go up and up and up) is the compilation of every file - when the peak is reached we then start weaving files one by one, discarding them once woven and dumped to disk. In 1.5.3 we don't compile everything up front - we compile and weave files one at a time. Giving us this profile:

`

      /\  /\  /\
     /  \/  \/  \
    /            \

`

Each peak is compiling a file, then it is woven, dumped to disk and the space recovered (the trough) - we then move onto the next file. What does this mean? The peaks are far far lower, so you need far less memory to compile a project. For example, I have a 1000file project, affected by aspects at >750 join points. For given values of Xmx, here are the times taken to compile it (on the command line) with AspectJ1.5.2:

    Xmx  Time
    512M 33seconds
    256M 40seconds
    220M 116seconds
    212M OutOfMemory

The times gradually increase as the memory is reduced because the VM starts to thrash in garbage collection. Here are the results for AspectJ1.5.3:

    Xmx  Time
    512M 33s
    256M 33s
    180M 33s
    140M 33s
    100M 35s
    80M  43s
    70M  OutOfMemory

So with 1.5.3, it isn't until around 80M that the VM starts to struggle with memory. These savings will affect any code built from source: on the command line, in Ant, or in AJDT. It will not affect binary weaving - that is a future enhancement.

## Serviceability - 150487

As AspectJ grows in popularity, we find that it is becoming more difficult for users to come up with the small testcases that recreate problems - the usage scenarios for AJ are becoming more and more sophisticated. To help us work on problems in these scenarios we have added a tracing and logging framework and improved our dump mechanism. These traces and dumps can be attached to bug reports. In AspectJ 1.5.3 we have included some documentation on how to configure these new features. Don't be surprised if you get asked for an AspectJ trace on a future bug report!

## LTW enhancements

### User and System Configuration Files - 149289

The `-outxml` option now generates a file named `META-INF/aop-ajc.xml`. This no longer clashes with a user defined `META-INF/aop.xml` configuration file. Both file names along with an OSGi-friendly `org/aspectj/aop.xml` (which can also be signed) are used by default to configure LTW.

### Weaving Concrete Aspects Defined in aop.xml - 132080

Concrete aspects defined using aop.xml are now exposed for weaving.

## Pertypewithin enhancement - 123423

It is now possible to ask an instance of a ptw aspect which type it is 'attached' to. The method:

`

    String getWithinTypeName()

`

can be called on an aspect and will return the full qualified name of the type (eg. "com.foo.MyClass")

For information on bug fixes in AspectJ 5 v1.5.3, see the changes document.