= AspectJ 5 v1.5.3 Readme

_© Copyright 2006 Contributors. All rights reserved._

This release includes a number of bug fixes and enhancements (over 80).
The full list of resolved issues can be found with
https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.5.3&long_desc_type=allwordssubstr&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&emailtype1=substring&email1=&emailtype2=substring&email2=&bugidtype=include&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=[this
bugzilla query].

Notable changes since the 1.5.2 release include: +

== Pipeline compilation - https://bugs.eclipse.org/bugs/show_bug.cgi?id=146781[146781]

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

[source, text]
....
     /\_
    /   \_
   /      \_
  /         \_
 /            \_
/               \
....

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:

[source, text]
....
  /\  /\  /\
 /  \/  \/  \
/            \
....

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:

[source, text]
....
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:

[source, text]
....
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 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=150487[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
https://www.eclipse.org/aspectj/doc/released/pdguide/index.html[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 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=149289[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 - https://bugs.eclipse.org/bugs/show_bug.cgi?id=132080[132080]

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

== Pertypewithin enhancement - https://bugs.eclipse.org/bugs/show_bug.cgi?id=123423[123423]

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

[source, java]
....
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
link:changes.html[changes] document.