blob: a10c65b6eb3c580539b6c0cb5bc8e70a54cd5440 [file] [log] [blame]
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html> <head>
<title>AspectJ 5 Development Kit v1.5.3 Readme</title>
<style type="text/css">
<!--
P { margin-left: 20px; }
PRE { margin-left: 20px; }
LI { margin-left: 20px; }
H4 { margin-left: 20px; }
H3 { margin-left: 10px; }
-->
</style>
</head>
<body>
<div align="right"><small>
&copy; Copyright 2006 Contributors.
All rights reserved.
</small></div>
<h1>AspectJ 5 v1.5.3 Readme</h1>
<p>This release includes a number of bug fixes and enhancements (over 80). The full list of resolved issues can be found with
<a href="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</a>.
</p>
<p>
Notable changes since the 1.5.2 release include:
<br>
<h2>Pipeline compilation - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=146781">146781</a></h2>
<p>Until this release, the memory profile for AspectJ looked like this (time is along the X axis, memory usage is the Y axis)</p>
<code><pre>
/\_
/ \_
/ \_
/ \_
/ \_
/ \
</pre></code>
<p>
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:
</p>
<code><pre>
/\ /\ /\
/ \/ \/ \
/ \
</pre></code>
<p>
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:</p>
<pre><code>
Xmx Time
512M 33seconds
256M 40seconds
220M 116seconds
212M OutOfMemory
</pre></code>
<p>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:</p>
<pre><code>
Xmx Time
512M 33s
256M 33s
180M 33s
140M 33s
100M 35s
80M 43s
70M OutOfMemory
</pre></code>
<p>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.</p>
<h2>Serviceability - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=150487">150487</a></h2>
<p>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 <a href="http://www.eclipse.org/aspectj/doc/released/pdguide/index.html">documentation</a> on how to configure these new features. Don't be surprised if you get asked
for an AspectJ trace on a future bug report!
</p>
<h2>LTW enhancements</h2>
<h3>User and System Configuration Files - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=149289">149289</a></h3>
<p>The <code>-outxml</code> option now generates a file named <code>META-INF/aop-ajc.xml</code>.
This no longer clashes with a user defined <code>META-INF/aop.xml</code> configuration file.
Both file names along with an OSGi-friendly <code>org/aspectj/aop.xml</code> (which can also be
signed) are used by default to configure LTW.</p>
<h3>Weaving Concrete Aspects Defined in aop.xml - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=132080">132080</a></h3>
<p>Concrete aspects defined using aop.xml are now exposed for weaving.</p>
<h2>Pertypewithin enhancement - <a href="https://bugs.eclipse.org/bugs/show_bug.cgi?id=123423">123423</a></h2>
<p>It is now possible to ask an instance of a ptw aspect which type it is 'attached' to. The method:</p>
<code><pre>String getWithinTypeName()</pre></code>
<p>can be called on an aspect and will return the full qualified name of the type (eg. "com.foo.MyClass")
</p>
<hr>
<p>For information on bug fixes in AspectJ 5 v1.5.3, see the <a href="changes.html"> changes</a> document.</p>
</body>
</html>