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:
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.
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!
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.
Concrete aspects defined using aop.xml are now exposed for weaving.
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.