From: Alexander Kriegisch <Alexander@Kriegisch.name>
Date: Thu, 4 Jan 2024 01:29:34 +0000 (+0700)
Subject: Bulk-rename release read-me files to version numbers with dots
X-Git-Tag: V1_9_21_1~68
X-Git-Url: https://source.dussan.org/?a=commitdiff_plain;h=f7962810eca3ddda75d64b85caab2449eeff480e;p=aspectj.git

Bulk-rename release read-me files to version numbers with dots

Also rename references. E.g.
  - RELEASE-11   -> RELEASE-1.1
  - RELEASE-1810 -> RELEASE-1.8.10
  - RELEASE-1921 -> RELEASE-1.9.21

Signed-off-by: Alexander Kriegisch <Alexander@Kriegisch.name>
---

diff --git a/build/release-checklist.txt b/build/release-checklist.txt
index d51d5f519..cdd57df6e 100644
--- a/build/release-checklist.txt
+++ b/build/release-checklist.txt
@@ -187,7 +187,7 @@ Installation & Verification Tests
 
 * check version in README-AspectJ.html                                  [   ]
 
-* check version in README-11.html (file not required)                   [   ]
+* check version in README-1.1.html (file not required)                   [   ]
 
 * check license present and correct version (currently CPLv1.0)         [   ]
 
diff --git a/docs/build.xml b/docs/build.xml
index 1f969df44..70799f969 100644
--- a/docs/build.xml
+++ b/docs/build.xml
@@ -155,11 +155,11 @@
         />
     </target>
 
-    <target name="web.deploy" depends="web.deploy.README-11" />
+    <target name="web.deploy" depends="web.deploy.README-1.1" />
 
-    <target name="web.deploy.README-11"
+    <target name="web.deploy.README-1.1"
             depends="init"
-            description="deploy README-11.html to the web site"
+            description="deploy README-1.1.html to the web site"
     >
         <property name="readme11.dir"
                   location="${web.doc.dir}/documentation/readme11"
@@ -168,7 +168,7 @@
         <delete file="${readme11.dir}/index.html" />
         <mkdir dir="${readme11.dir}" />
         <copy tofile="${readme11.dir}/index.html"
-              file="${aspectj.products.dir}/tools/dist/README-11.html"
+              file="${aspectj.products.dir}/tools/dist/README-1.1.html"
               filtering="on"
         />
         <stripnonbodyhtml srcdir="${readme11.dir}"
diff --git a/docs/dist/doc/README-1.1.adoc b/docs/dist/doc/README-1.1.adoc
new file mode 100644
index 000000000..d846cff81
--- /dev/null
+++ b/docs/dist/doc/README-1.1.adoc
@@ -0,0 +1,1381 @@
+[[readme-1_1]]
+== AspectJ 1.1
+
+_© Copyright 2002 Palo Alto Research Center, Incorporated, 2003
+Contributors. All rights reserved._
+
+This is the initial release of AspectJ 1.1. It includes a small number
+of new language features as well as major improvements to the
+functionality of the tools.
+
+This document describes the differences between AspectJ versions 1.1 and
+1.0.6. Users new to AspectJ need only read the
+link:progguide/index.html[AspectJ Programming Guide] since it describes
+the 1.1 language. Users familiar with AspectJ 1.0 may find this document
+a quicker way to learn what changed in the language and tools, and
+should use it as a guide for porting programs from 1.0 to 1.1.
+
+This document first summarizes changes from the 1.0 release in
+
+* xref:#language[the language],
+* xref:#compiler[the compiler],
+* xref:#tools[the support tools],
+* xref:#runtime[the runtime],
+* xref:#devenv[the development environment support],
+* xref:#sources[the sources], and
+* xref:#distribution[the distribution],
+
+then xref:#details[details] some of the language and compiler changes,
+and finally points readers to the bug database for any
+xref:#knownLimitations[known limitations].
+
+'''''
+
+[[language]]
+=== The Language
+
+AspectJ 1.1 is a slightly different language than AspectJ 1.0. In all
+but a few cases, programs written in AspectJ 1.0 should compile
+correctly in AspectJ 1.1. In many cases, there are new or preferred
+forms in AspectJ 1.1. However, some AspectJ 1.0 features have changed in
+1.1, so some 1.0 programs will not compile or will run differently in
+1.1. The corresponding features are marked below as compile-time or
+run-time incompatible (_CTI_ or _RTI_, respectively). When the language
+change involves a move in the static shadow effective at run-time but
+also apparent at compile-time (e.g., in declare error or warning
+statements), it is marked _CRTI_. Programs using run-time incompatible
+forms should be verified that they are behaving as expected in 1.1.
+
+Most changes to the language are additions to expressibility requested
+by our users:
+
+* xref:#THROWS_PATTERN[Matching based on throws]: You can now make finer
+discriminations between methods based on declared exceptions.
+* xref:#NEW_PCDS[New kinded pointcut designators]: Now every kind of
+join point has a corresponding kinded pointcut designator.
+
+Some are have different behavior in edge cases but offer improved power
+and clarity:
+
+* xref:#ASPECT_PRECEDENCE[New aspect precedence form]: AspectJ 1.1 has a
+new declare form, `declare     precedence`, that replaces the
+"dominates" clause on aspects. (_CTI_)
+* The order of xref:#SUPER_IFACE_INITS[initialization join points for
+super-interfaces] has been clarified. (_RTI_)
+
+But in order to support weaving into bytecode effectively, several
+incompatible changes had to be made to the language:
+
+* A class's default constructor may
+xref:#DEFAULT_CONSTRUCTOR_CONFLICT[conflict] with an inter-type
+constructor. (_CTI_)
+* xref:#NO_CALLEE_SIDE_CALL[No callee-side call join points]: The
+AspectJ 1.1 compiler does not expose call join points unless it is given
+the calling code. (_CRTI_)
+* xref:#SINGLE_INTERCLASS_TARGET[One target for intertype declarations].
+(_CTI_)
+* xref:#UNAVAILABLE_JOIN_POINTS[No initializer execution join points].
+(_RTI_)
+* xref:#AFTER_HANDLER[No after or around advice on handler join points].
+(_CTI_)
+* xref:#CONSTRUCTOR_EXECUTION_IS_BIGGER[Initializers run inside
+constructor execution join points]. (_RTI_)
+* xref:#INTER_TYPE_FIELD_INITIALIZERS[inter-type field initializers] run
+before class-local field initializers. (_RTI_)
+* xref:#WITHIN_MEMBER_TYPES[Small limitations of the within pointcut.]
+(_CRTI_)
+* xref:#WITHIN_CODE[Small limitations of the withincode pointcut.]
+(_CRTI_)
+* xref:#INSTANCEOF_ON_WILD[Can't do instanceof matching on type patterns
+with wildcards]. (_CTI_)
+* xref:#NO_SOURCE_COLUMN[SourceLocation.getColumn() is deprecated and
+will always return 0]. (_RTI_)
+* The interaction between aspect instantiation and advice has been
+xref:#ASPECT_INSTANTIATION_AND_ADVICE[clarified]. (_RTI_)
+* xref:#STRINGBUFFER[The String + operator is now correctly advised].
+(_CRTI_)
+
+[#NEW_LIMITATIONS]#There# are a couple of language limitations for
+things that are rarely used that make the implementation simpler, so we
+have restricted the language accordingly.
+
+* xref:#VOID_FIELD_SET[Field set join points now have a `void` return
+type.] This will require porting of code that uses the `set` PCD in
+conjunction with after-returning or around advice. (_CTI_)
+* 'declare soft: TYPE: POINTCUT;' - AspectJ 1.1 only accepts TYPE rather
+than a TYPE_PATTERN. This limitation makes declare soft much easier to
+implement efficiently. (_CTI_)
+* Inter-type field declarations only allow a single field per line, i.e.
+this is now illegal 'int C.field1, D.field2;' This must instead be, 'int
+C.field1; int D.field2;' (_CTI_)
+* We did not implement the handling of more than one `..` wildcard in
+args PCD's (rarely encountered in the wild) because we didn't have the
+time. This might be available in later releases if there is significant
+outcry. (_CTI_)
+
+We did not implement the long-awaited xref:#PER_TYPE[new pertype aspect
+specifier] in this release, but it may well be in a future release.
+
+'''''
+
+[[compiler]]
+=== The Compiler
+
+The compiler for AspectJ 1.1 is different than the compiler for AspectJ
+1.0. While this document describes the differences in the compiler, it's
+worthwhile noting that much effort has been made to make sure that the
+interface to ajc 1.1 is, as much as possible, the same as the interface
+to ajc 1.0. There are two important changes under the hood, however.
+
+First, the 1.1 compiler is implemented on top of the open-source Eclipse
+compiler. This has two benefits: It allows us to concentrate on the
+AspectJ extensions to Java and let the Eclipse team worry about making
+sure the Java edge cases work, and it allows us to piggyback on
+Eclipse's already mature incremental compilation facilities.
+
+Second, ajc now cleanly delineates compilation of source code from
+assembly (or "weaving") of bytecode. The compiler still accepts source
+code, but internally it transforms it into bytecode format before
+weaving.
+
+This new architecture, and other changes to the compiler, allows us to
+implement some features that were defined in the AspectJ 1.0 language
+but not implementable in the 1.1 compiler. It also makes some new
+features available:
+
+* xref:#SOURCEROOT[The -sourceroots option] takes one or more
+directories, and indicates that all the source files in those
+directories should be passed to the compiler.
+* xref:#BYTECODE_WEAVING[The -injars option] takes one or more jar
+files, and indicates that all the classfiles in the jar files should be
+woven into.
+* xref:#BINARY_ASPECTS[The -aspectpath option] takes one or more jar
+files, and weaves any aspects in .class form into the sources.
+* xref:#OUTJAR[The -outjar option] indicates that the result classfiles
+of compiling and weaving should be placed in the specified jar file.
+* xref:#XLINT[The -Xlint option] allows control over warnings.
+* xref:#OTHER_X_OPTIONS[Various -X options] changed.
+* xref:#INCREMENTAL[The -incremental option] tells the AspectJ 1.1
+compiler to recompile only as necessary.
+
+Some other features we wanted to support for 1.1, but did not make it
+into this release:
+
+* xref:#ERROR_MESSAGES[Error messages will sometimes be scary]
+* xref:#MESSAGE_CONTEXT[Source code context is not shown for errors and
+warnings detected during bytecode weaving]
+
+But some features of the 1.0 compiler are not supported in the 1.1
+compiler:
+
+* xref:#NO_SOURCE[The source-related options] -preprocess, -usejavac,
+-nocomment and -workingdir
+* xref:#NO_STRICT_LENIENT[The -strict and -lenient options]
+* xref:#NO_PORTING[The -porting option]
+* xref:#_13_REQUIRED[J2SE 1.2 is not supported; J2SE 1.3 or later is
+required.]
+
+A short description of the options ajc accepts is available with
+"`ajc -help`". Longer descriptions are available in the
+link:devguide/ajc-ref.html[Development Environment Guide section on
+ajc].
+
+Some changes to the implementation are almost entirely internal:
+
+* The behavior of the compiler in xref:#TARGET_TYPES_MADE_PUBLIC[lifting
+the visibility] of the target types of some declares and pointcuts to
+public has been clarified.
+
+Also, it is worth noting that because AspectJ now works on bytecode, it
+is somewhat sensitive to how different compilers generate bytecode,
+especially when compiling with and without
+xref:#ONE_FOUR_METHOD_SIGNATURES[the -1.4 flag].
+
+'''''
+
+[[tools]]
+=== Support Tools
+
+This release includes an Ant task for old-style 1.0 build scripts, a new
+task for all the new compiler options, and a CompilerAdapter to support
+running `ajc` with the Javac task by setting the `build.compiler`
+property. The new task can automatically copy input resources to output
+and work in incremental mode using a "tag" file.
+
+This release does not include `ajdoc`, the documentation tool for
+AspectJ sources. Ajdoc is deeply dependent on the abstract syntax tree
+classes from the old compiler, so it needs a bottom-up rewrite. We think
+it best to use this opportunity to implement more general API's for
+publishing and rendering static structure. Because those API's are last
+to settle in the new architecture, and because the compiler itself is a
+higher priority, we are delaying work on ajdoc until after the 1.1
+release.
+
+AspectJ 1.1 will not include ajdb, the AspectJ stand-alone debugger. It
+is no longer necessary for two reasons. First, the -XnoInline flag will
+tell the compiler to generate code without inlining that should work
+correctly with any Java debugger. For code generated with inlining
+enabled, more third-party debuggers are starting to work according to
+JSR 45, "Debugging support for other languages," which is supported by
+AspectJ 1.0. We aim to support JSR-45 in AspectJ 1.1, but support will
+not be in the initial release. Consider using the -XnoInline flag until
+support is available.
+
+'''''
+
+[[runtime]]
+=== The Runtime Library
+
+This release has minor additions to the runtime library classes. As with
+any release, you should compile and run with the runtime library that
+came with your compiler, and you may run with a later version of the
+library without recompiling your code.
+
+In one instance, however, runtime classes behave differently this
+release. Because the AspectJ 1.1 compiler does its weaving through
+bytecode, column numbers of source locations are not available.
+Therefore, `thisJoinPoint.getSourceLocation().getColumn()` is deprecated
+and will always return 0.
+
+'''''
+
+[[devenv]]
+=== The AJDE Tools
+
+The AspectJ Browser supports incremental compilation and running
+programs. AJDE for JBuilder, AJDE for NetBeans, and AJDE for Emacs are
+now independent SourceForge projects (to keep their licenses). They use
+the batch-build mode of the new compiler.
+
+'''''
+
+[[sources]]
+=== The Sources and the Licenses
+
+The AspectJ tools sources are available under the
+https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.txt[Eclipse Public
+License v 2.0] in the Git repository at https://eclipse.org/aspectj. For
+more information, see the FAQ entry on building sources.
+
+'''''
+
+[[distribution]]
+=== The AspectJ distribution
+
+AspectJ 1.0 had many distributions - for the tools, the documentation,
+each IDE support package, their respective sources, and the Ant tasks -
+because they came under different licenses. All of AspectJ 1.1 is
+licensed under the CPL 1.0, so the tools, Ant tasks, and documentation
+are all in one distribution available from https://eclipse.org/aspectj.
+To retain their MPL 1.1 license, Ajde for
+http://aspectj4emacs.sourceforge.net/[Emacs],
+http://aspectj4netbean.sourceforge.net/[NetBeans] and
+http://aspectj4jbuildr.sourceforge.net/[JBuilder] are now independent
+SourceForge projects.
+
+'''''
+
+'''''
+
+[[details]]
+=== Details of some language and compiler changes
+
+[[ASPECT_INSTANTIATION_AND_ADVICE]]
+==== Aspect Instantiation and Advice
+
+In AspectJ 1.0.6, we made an effort to hide some complications with
+Aspect instantiation from the user. In particular, the following code
+compiled and ran:
+
+[source, java]
+....
+public class Client {
+    public static void main(String[] args) {
+        Client c = new Client();
+    }
+}
+
+aspect Watchcall {
+    pointcut myConstructor(): execution(new(..));
+
+    before(): myConstructor() {
+        System.err.println("Entering Constructor");
+    }
+}
+....
+
+But there's a conceptual problem with this code: The before advice
+should run before the execution of all constructors in the system. It
+must run in the context of an instance of the Watchcall aspect. The only
+way to get such an instance is to have Watchcall's default constructor
+execute. But before that executes, we need to run the before advice...
+
+AspectJ 1.0.6 hid this circularity through the ad-hoc mechanism of
+preventing an aspect's advice from matching join points that were within
+the aspect's definition, and occurred before the aspect was initialized.
+But even in AspectJ 1.0.6, this circularity could be exposed:
+
+[source, java]
+....
+public class Client {
+    public static int foo() { return 3; }
+    public static void main(String[] args) {
+        Client c = new Client();
+    }
+}
+
+aspect Watchcall {
+    int i = Client.foo();
+    pointcut myConstructor():
+        execution(new(..)) || execution(int foo());
+
+    before(): myConstructor() {
+        System.err.println("Entering Constructor");
+    }
+}
+....
+
+This program would throw a NullPointerException when run, since
+Client.foo() was called before the Watchcall instance could be
+instantiated.
+
+In AspectJ 1.1, we have decided that half-hiding the problem just leads
+to trouble, and so we are no longer silently hiding some join points
+before aspect initialization. However, we have provided a better
+exception than a NullPointerException for this case. In AspectJ 1.1,
+both of the above programs will throw
+org.aspectj.lang.NoAspectBoundException.
+
+[[THROWS_PATTERN]]
+==== Matching based on throws
+
+Type patterns may now be used to pick out methods and constructors based
+on their throws clauses. This allows the following two kinds of
+extremely wildcarded pointcuts:
+
+[source, java]
+....
+pointcut throwsMathlike():
+  // each call to a method with a throws clause containing at least
+  // one exception with "Math" in its name.
+  call(* *(..) throws *..*Math*);
+
+pointcut doesNotThrowMathlike():
+  // each call to a method with a throws clause containing no
+  // exceptions with "Math" in its name.
+  call(* *(..) throws !*..*Math*);
+....
+
+The longwinded rules are that a method or constructor pattern can have a
+"throws clause pattern". Throws clause patterns look like:
+
+[source, text]
+....
+ThrowsClausePattern:
+    ThrowsClausePatternItem ("," ThrowsClausePatternItem)*
+
+ThrowsClausePatternItem:
+    ["!"] TypeNamePattern
+....
+
+A ThrowsClausePattern matches the ThrowsClause of any code member
+signature. To match, each ThrowsClausePatternItem must match the throws
+clause of the member in question. If any item doesn't match, then the
+whole pattern doesn't match. This rule is unchanged from AspectJ 1.0.
+
+If a ThrowsClausePatternItem begins with "!", then it matches a
+particular throws clause if and only if _none_ of the types named in the
+throws clause is matched by the TypeNamePattern.
+
+If a ThrowsClausePatternItem does not begin with "!", then it matches a
+throws clause if and only if _any_ of the types named in the throws
+clause is matched by the TypeNamePattern.
+
+These rules are completely backwards compatible with AspectJ 1.0. The
+rule for "!" matching has one potentially surprising property, in that
+the two PCD's shown below will have different matching rules.
+
+[source, java]
+....
+/*[1]*/ call(* *(..) throws !IOException)
+/*[2]*/ call(* *(..) throws (!IOException))
+
+void m() throws RuntimeException, IOException {}
+....
+
+[1] will NOT match the method m(), because method m's throws clause
+declares that it throws IOException. [2] WILL match the method m(),
+because method m's throws clause declares the it throws some exception
+which does not match IOException, i.e. RuntimeException.
+
+[[NEW_PCDS]]
+==== New kinded pointcut designators
+
+AspectJ 1.0 does not provide kinded pointcut designators for two (rarely
+used) join points: preinitialization (the code that runs before a super
+constructor call is made) and advice execution. AspectJ 1.1 does not
+change the meaning of the join points, but provides two new pointcut
+designators to pick out these join points, thus making join points and
+pointcut designators more parallel.
+
+`adviceexectuion()` will pick out advice execution join points. You will
+usually want to use `adviceexecution()     && within(Aspect)` to
+restrict it to only those pieces of advice defined in a particular
+aspect. +
+`preinitialization(ConstructorPattern)` will pick out pre-initialization
+join points where the initialization process is entered through
+`ConstructorPattern`.
+
+[[PER_TYPE]]
+==== New pertype aspect specifier (not in 1.1)
+
+We strongly considered adding a pertype aspect kind to 1.1. This is
+somewhat motivated by the new
+xref:#SINGLE_INTERCLASS_TARGET[restrictions on inter-type declarations]
+
+. This is also motivated by many previous request to support a common
+logging idiom. Here's what pertype would look like:
+
+[source, java]
+....
+/** One instance of this aspect will be created for each class,
+ * interface or aspect in the com.bigboxco packages.
+ */
+aspect Logger pertype(com.bigboxco..*) {
+    /* This field holds a logger for the class. */
+    Log log;
+
+    /* This advice will run for every public execution defined by
+     * a type for which a Logger aspect has been created, i.e.
+     * any type in com.bigboxco..*
+     */
+    before(): execution(public * *(..)) {
+        log.enterMethod(thisJoinPoint.getSignature().getName());
+    }
+
+    /* We can use a special constructor to initialize the log field */
+    public Logger(Class myType) {
+        this.log = new Log(myType);
+    }
+}
+
+/** External code could use aspectOf to get at the log, i.e. */
+Log l = Logger.aspectOf(com.bigboxco.Foo.class).log;
+....
+
+The one open question that we see is how this should interact with inner
+types. If a pertype aspect is created for an outer type should advice in
+that aspect run for join points in inner types? That is the behavior of
+the most common uses of this idiom.
+
+In any case, this feature will not be in AspectJ 1.1.
+
+[[SINGLE_INTERCLASS_TARGET]]
+==== One target for intertype declarations
+
+Intertype declarations (once called "introductions") in AspectJ 1.1 can
+only have one target type. So the following code intended to declare
+that there is a void doStuff() method on all subtypes of Target is not
+legal AspectJ 1.1 code.
+
+[source, java]
+....
+aspect A {
+    public void Target+.doStuff() { ... }
+}
+....
+
+The functionality of "multi-intertype declarations" can be recovered by
+using a helper interface.
+
+[source, java]
+....
+aspect A {
+    private interface MyTarget {}
+    declare parents:  Target+ implements MyTarget;
+    public void MyTarget.doStuff() { ... }
+}
+....
+
+We believe this is better style in AspectJ 1.0 as well, as it makes
+clear the static type of "this" inside the method body.
+
+The one piece of functionality that can not be easily recovered is the
+ability to add static fields to many classes. We believe that the
+xref:#PER_TYPE[pertype proposal] provides this functionality in a much
+more usable form.
+
+[[UNAVAILABLE_JOIN_POINTS]]
+==== No initializer execution join points
+
+AspectJ 1.1 does not consider initializer execution a principled join
+point. The collection of initializer code (the code that sets fields
+with initializers and the code in non-static initializer blocks) is
+something that makes sense only in Java source code, not in Java
+bytecode.
+
+[[AFTER_HANDLER]]
+==== No after or around advice on handler join points
+
+The end of an exception handler is underdetermined in bytecode, so ajc
+will not implement after or around advice on handler join points,
+instead signaling a compile-time error.
+
+[[CONSTRUCTOR_EXECUTION_IS_BIGGER]]
+==== Initializers run inside constructor execution join points
+
+The code generated by the initializers in Java source code now runs
+inside of constructor execution join points. This changes how before
+advice runs on constructor execution join points. Consider:
+
+[source, java]
+....
+class C {
+    C() { }
+    String id = "identifier"; // this assignment
+                              // has to happen sometime
+}
+
+aspect A {
+    before(C c) this(c) && execution(C.new()) {
+        System.out.println(c.id.length());
+    }
+}
+....
+
+In AspectJ 1.0, this will print "10", since id is assigned its initial
+value prior to the before advice's execution. However, in AspectJ 1.1,
+this will throw a NullPointerExcception, since "id" does not have a
+value prior to the before advice's execution.
+
+Note that the various flavors of after returning advice are unchanged in
+this respect in AspectJ 1.1. Also note that this only matters for the
+execution of constructors that call a super-constructor. Execution of
+constructors that call a this-constructor are the same in AspectJ 1.1 as
+in AspectJ 1.0.
+
+We believe this difference should be minimal to real programs, since
+programmers using before advice on constructor execution must always
+assume incomplete object initialization, since the constructor has not
+yet run.
+
+[[INTER_TYPE_FIELD_INITIALIZERS]]
+==== Inter-type field initializers
+
+The initializer, if any, of an inter-type field definition runs before
+the class-local initializers of its target class.
+
+In AspectJ 1.0.6, such an initializer would run after the initializers
+of a class but before the execution of any of its constructor bodies. As
+already discussed in the sections about
+xref:#UNAVAILABLE_JOIN_POINTS[initializer execution join points] and
+xref:#CONSTRUCTOR_EXECUTION_IS_BIGGER[constructor execution], the point
+in code between the initializers of a class and its constructor body is
+not principled in bytecode. So we had a choice of running the
+initializer of an inter-type field definition at the beginning of
+initialization (i.e., before initializers from the target class) or at
+the end (i.e., just before its called constructor exits). We chose the
+former, having this pattern in mind:
+
+[source, java]
+....
+int C.methodCount = 0;
+before(C c): this(c) && execution(* *(..)) { c.methodCount++; }
+....
+
+We felt there would be too much surprise if a constructor called a
+method (thus incrementing the method count) and then the field was reset
+to zero after the constructor was done.
+
+[[WITHIN_MEMBER_TYPES]]
+==== Small limitations of the within pointcut
+
+Because of the guarantees made (and not made) by the Java classfile
+format, there are cases where AspectJ 1.1 cannot guarantee that the
+within pointcut designator will pick out all code that was originally
+within the source code of a certain type.
+
+The non-guarantee applies to code inside of anonymous and local types
+inside member types. While the within pointcut designator behaves
+exactly as it did in AspectJ 1.0 when given a package-level type (like
+C, below), if given a member-type (like C.InsideC, below), it is not
+guaranteed to capture code in contained local and anonymous types. For
+example:
+
+[source, java]
+....
+class C {
+    Thread t;
+    class InsideC {
+        void setupOuterThread() {
+            t = new Thread(
+                    new Runnable() {
+                        public void run() {
+                            // join points with code here
+                            // might not be captured by
+                            // within(C.InsideC), but are
+                            // captured by within(C)
+                            System.out.println("hi");
+                        }
+                    });
+        }
+    }
+}
+....
+
+We believe the non-guarantee is small, and we haven't verified that it
+is a problem in practice.
+
+[[WITHIN_CODE]]
+==== Small limitations of the withincode pointcut
+
+The withincode pointcut has similar issues to those described above for
+within.
+
+[[INSTANCEOF_ON_WILD]]
+==== Can't do instanceof matching on type patterns with wildcard
+
+The pointcut designators this, target and args specify a dynamic test on
+their argument. These tests can not be performed on type patterns with
+wildcards in them. The following code that compiled under 1.0 will be an
+error in AspectJ-1.1:
+
+[source, java]
+....
+pointcut oneOfMine(): this(com.bigboxco..*);
+....
+
+The only way to implement this kind of matching in a modular way would
+be to use the reflection API at runtime on the Class of the object. This
+would have a very high performance cost and possible security issues.
+There are two good work-arounds. If you control the source or bytecode
+to the type you want to match then you can use declare parents, i.e.:
+
+[source, java]
+....
+private interface OneOfMine {}
+declare parents: com.bigboxco..* implements OneOfMine;
+pointcut oneOfMine(): this(OneOfMine);
+....
+
+If you want the more dynamic matching and are willing to pay for the
+performance, then you should use the Java reflection API combined with
+if. That would look something like:
+
+[source, java]
+....
+pointcut oneOfMine(): this(Object) &&
+    if(classMatches("com.bigboxco..*",
+                    thisJoinPoint.getTarget().getClass()));
+
+static boolean classMatches(String pattern, Class _class) {
+    if (patternMatches(pattern, _class.getName())) return true;
+    ...
+}
+....
+
+Note: wildcard type matching still works in all other PCD's that match
+based on static types. So, you can use 'within(com.bigboxco..*+)' to
+match any code lexically within one of your classes or a subtype
+thereof. This is often a good choice.
+
+[[NO_SOURCE_COLUMN]]
+==== SourceLocation.getColumn()
+
+The Java .class file format contains information about the source file
+and line numbers of its contents; however, it has no information about
+source columns. As a result, we can not effectively support the access
+of column information in the reflection API. So, any calls to
+thisJoinPoint.getSourceLocation().getColumn() will be marked as
+deprecated by the compiler, and will always return 0.
+
+[[ASPECT_PRECEDENCE]]
+==== Aspect precedence
+
+AspectJ 1.1 has a new declare form:
+
+[source, java]
+....
+declare precedence ":"  TypePatternList ";"
+....
+
+This is used to declare advice ordering constraints on join points. For
+example, the constraints that (1) aspects that have Security as part of
+their name should dominate all other aspects, and (2) the Logging aspect
+(and any aspect that extends it) should dominate all non-security
+aspects, can be expressed by:
+
+[source, java]
+....
+declare precedence: *..*Security*, Logging+, *;
+....
+
+In the TypePatternList, the wildcard * means "any type not matched by
+another type in the declare precedence".
+
+===== Various cycles
+
+It is an error for any aspect to be matched by more than one TypePattern
+in a single declare precedence, so:
+
+[source, java]
+....
+declare precedence:  A, B, A ;  // error
+....
+
+However, multiple declare precedence forms may legally have this kind of
+circularity. For example, each of these declare precedence is perfectly
+legal:
+
+[source, java]
+....
+declare precedence: B, A;
+declare precedence: A, B;
+....
+
+And a system in which both constraints are active may also be legal, so
+long as advice from A and B don't share a join point. So this is an
+idiom that can be used to enforce that A and B are strongly independent.
+
+===== Applies to concrete aspects
+
+Consider the following library aspects:
+
+[source, java]
+....
+abstract aspect Logging {
+    abstract pointcut logged();
+
+    before(): logged() {
+        System.err.println("thisJoinPoint: " + thisJoinPoint);
+    }
+}
+
+aspect MyProfiling {
+    abstract pointcut profiled();
+
+    Object around(): profiled() {
+        long beforeTime = System.currentTimeMillis();
+        try {
+            return proceed();
+        } finally {
+            long afterTime = System.currentTimeMillis();
+            addToProfile(thisJoinPointStaticPart,
+                         afterTime - beforeTime);
+        }
+    }
+    abstract void addToProfile(
+        org.aspectj.JoinPoint.StaticPart jp,
+        long elapsed);
+}
+....
+
+In order to use either aspect, they must be extended with concrete
+aspects, say, MyLogging and MyProfiling. In AspectJ 1.0, it was not
+possible to express that Logging's advice (when concerned with the
+concrete aspect MyLogging) dominated Profiling's advice (when concerned
+with the concrete aspect MyProfiling) without adding a dominates clause
+to Logging itself. In AspectJ 1.1, we can express that constraint with a
+simple:
+
+[source, java]
+....
+declare precedence: MyLogging, MyProfiling;
+....
+
+===== Changing order of advice for sub-aspects
+
+By default, advice in a sub-aspect has more precedence than advice in a
+super-aspect. One use of the AspectJ 1.0 dominates form was to change
+this precedence:
+
+[source, java]
+....
+abstract aspect SuperA dominates SubA {
+    pointcut foo(): ... ;
+
+    before(): foo() {
+        // in AspectJ 1.0, runs before the advice in SubA
+        // because of the dominates clause
+    }
+}
+
+aspect SubA extends SuperA {
+    before(): foo() {
+        // in AspectJ 1.0, runs after the advice in SuperA
+        // because of the dominates clause
+    }
+}
+....
+
+This no longer works in AspectJ 1.1, since declare precedence only
+matters for concrete aspects. Thus, if you want to regain this kind of
+precedence change, you will need to refactor your aspects.
+
+[[SOURCEROOT]]
+==== The -sourceroots option
+
+The AspectJ 1.1 compiler now accepts a -sourceroots option used to pass
+all .java files in particular directories to the compiler. It takes
+either a single directory name, or a list of directory names separated
+with the CLASSPATH separator character (":" for various Unices, ";" for
+various Windows).
+
+So, if you have your project separated into a gui module and a base
+module, each of which is stored in a directory tree, you might use one
+of
+
+[source, text]
+....
+ajc -sourceroots /myProject/gui:/myProject/base
+ajc -sourceroots d:\myProject\gui;d:\myProject\base
+....
+
+This option may be used in conjunction with lst files, listing .java
+files on the command line, and the -injars option.
+
+[[BYTECODE_WEAVING]]
+==== The -injars option
+
+The AspectJ 1.1 compiler now accepts an -injars option used to pass all
+.class files in a particular jar file to the compiler. It takes either a
+single directory name, or a list of directory names separated with the
+CLASSPATH separator character (":" for various Unices, ";" for various
+Windows).
+
+So, if MyTracing.java defines a trace aspect that you want to apply to
+all the classes in myBase.jar and myGui.jar, you would use one of:
+
+[source, text]
+....
+ajc -injars /bin/myBase.jar:/bin/myGui.jar MyTracing.java
+ajc -injars d:\bin\myBase.jar;d:\bin\myGui.jar MyTracing.java
+....
+
+The class files in the input jars must not have had advice woven into
+them, since AspectJ enforces the requirement that advice is woven into a
+particular classfile only once. So if the classfiles in the jar file are
+to be created with the ajc compiler (as opposed to a pure Java
+compiler), they should not be compiled with any non-abstract aspects.
+
+This option may be used in conjunction with lst files, listing .java
+files on the command line, and the -sourceroots option.
+
+[[OUTJAR]]
+==== The -outjar option
+
+The -outjar option takes the name of a jar file into which the results
+of the compilation should be put. For example:
+
+[source, text]
+....
+ajc -injars myBase.jar MyTracing.java -outjar myTracedBase.jar
+....
+
+No meta information is placed in the output jar file.
+
+[[INCREMENTAL]]
+==== Incremental compilation
+
+The AspectJ 1.1 compiler now supports incremental compilation. When ajc
+is called with the -incremental option, it must also be passed a
+-sourceroots option specifying a directory to incrementally compile.
+Once the initial compile is done, ajc waits for console input. Every
+time it reads a new line (i.e., every time the user hits return) ajc
+recompiles those input files that need recompiling.
+
+===== Limitations
+
+This new functionality is still only lightly tested.
+
+[[XNOWEAVE]]
+==== -XnoWeave, a compiler option to suppress weaving
+
+The -XnoWeave option suppresses weaving, and generates classfiles and
+that can be passed to ajc again (through the -injars option) to generate
+final, woven classfiles.
+
+This option was originally envisioned to be the primary way to generate
+binary aspects that could be linked with other code, and so it was
+previously (in AspectJ 1.1beta1) named `-noweave`. We feel that using
+the `-aspectpath` option is a much better option. There may still be use
+cases for unwoven classfiles, but we've moved the flag to experimental
+status.
+
+[[BINARY_ASPECTS]]
+==== -aspectpath, working with aspects in .class/.jar form
+
+When aspects are compiled into classfiles, they include all information
+necessary for the ajc compiler to weave their advice and deal with their
+inter-type declarations. In order for these aspects to have an effect on
+a compilation process, they must be passed to the compiler on the
+-aspectpath. Every .jar file on this path will be searched for aspects
+and any aspects that are found will be enabled during the compilation.
+The binary forms of this aspects will be untouched.
+
+[[NO_CALLEE_SIDE_CALL]]
+==== Callee-side call join points
+
+The 1.0 implementation of AspectJ, when given:
+
+[source, java]
+....
+class MyRunnable implements Runnable {
+    public void run() { /*...*/ }
+}
+
+aspect A {
+    call(): (void run()) && target(MyRunnable) {
+        // do something here
+    }
+}
+....
+
+would cause A's advice to execute even when, say, java.lang.Thread
+called run() on a MyRunnable instance.
+
+With the new compiler, two things have happened in regard to callee-side
+calls:
+
+. because the programmer has access to more code (i.e., bytecode, not
+just source code), callee-side calls are much less important to have.
+. because compilation is more modular, allowing and encouraging separate
+compilation, callee-side calls are much more difficult to implement
+
+With these two points in mind, advice in an aspect will not be applied
+to call join points whose call site is completely unavailable to the
+aspect.
+
+. One reason (though not the only reason) we worked so hard in the
+_implementation_ of 1.0.6 to expose call join points, even if we only
+had access to the callee's code, was that otherwise users couldn't get
+access to call join points where the call was made from bytecode. This
+is no longer the case. In short, the implementation controls much more
+code (or has the capability to) than ever before.
+. The implementation model for the AspectJ 1.1 compiler is to separate
+the compilation of aspects/advice from their weaving/linking. A property
+of the model is that the compilation requires no access to "target"
+code, only the weaving/linking does, and weaving/linking is inherently
+per-class local: No action at weaving/linking time depends on the
+coordinated mangling of multiple classfiles. Rather, all weaving is done
+on a per classfile basis. This is an essential property for the current
+separate compilation model. +
+However, allowing implementation of call advice on either side requires
+simultaneous knowledge of both sides. If we first have access to a call,
+we can't decide to simply put the advice on the call site, since later
+we may decide to implement on the callee.
+
+This implementation decision is completely in the letter and the spirit
+of the AspectJ language. From the semantics guide describing code the
+implementation controls:
+
+____
+But AspectJ implementations are permitted to deviate from this in a
+well-defined way -- they are permitted to advise only accesses in _code
+the implementation controls_. Each implementation is free within certain
+bounds to provide its own definition of what it means to control code.
+____
+
+And about a particular decision about the 1.0.6 implementation:
+
+____
+Different join points have different requirements. Method call join
+points can be advised only if ajc controls _either_ the code for the
+caller or the code for the receiver, and some call pointcut designators
+may require caller context (what the static type of the receiver is, for
+example) to pick out join points.
+____
+
+The 1.1 implementation makes a different design decision: Method call
+join points can be advised only if ajc (in compiler or linker form)
+controls the code for the caller.
+
+What does 1.1 gain from this?
+
+* a clear (and implemented) separate compilation model (see point 2,
+above)
+* a less confusing interaction between call join points and the
+thisJoinPoint reflective object: We still get bug reports about source
+information sometimes existing and sometimes not existing at call join
+points.
+
+What does 1.1 lose from this?
+
+* The ability to capture all calls to Runnable.run() from anywhere to
+code ajc has access too, even from Thread, even if you don't compile
+java.lang with ajc.
+* The ability to, without access to the caller, capture entry to a
+particular method, but not super calls.
+* A code-size-improvement performance optimization.
+
+What are the possibilities for the future?
+
+* AspectJ 1.1.1 could expand its capture of call join points, possibly
+at the expense of separate compilation clarity, possibly not.
+* AspectJ 1.1.1 could re-introduce reception join points from AspectJ
+0.7 (what callee-side call join points actually are): though they would
+never ever be taught in a tutorial or entry-level description of the
+model, they may have specialized uses.
+
+How will this affect developers?
+
+* When using the call PCD but only supplying the callee code, supply the
+calling code or use the execution PCD instead.
+
+[[OTHER_X_OPTIONS]]
+==== Various -X options
+
+The AspectJ 1.0 compiler supported a number of options that started with
+X, for "experimental". Some of them will not be supported in 1.1, either
+because the "experiment" succeeded (in which case it's part of the
+normal functionality) or failed. Others will be supported as is (or
+nearly so) in 1.1:
+
+* -XOcodeSize: This is no longer necessary because inlining of around
+advice is on by default. We support its inverse,
+xref:#XNOINLINE[`-XnoInline`].
+* xref:#XNOWEAVE[-XnoWeave, a compiler option to suppress weaving]
+* -XtargetNearSource: Not supported in this release.
+* -XserializableAspects: Supported.
+* -XaddSafePrefix: This option will not be supported in 1.1 at all
+because we're now always using (what we believe to be) safe prefixes.
+* -Xlint: Still supported, with xref:#XLINT[various options].
+
+[[ERROR_MESSAGES]]
+==== Some confusing error messages
+
+Building on the eclipse compiler has given us access to a very
+sophisticated problem reporting system as well as highly optimized error
+messages for pure Java code. Often this leads to noticeably better error
+messages than from ajc-1.0.6. However, when we don't handle errors
+correctly this can sometimes lead to cascading error messages where a
+single small syntax error will produce dozens of other messages. Please
+report any very confusing error messages as bugs.
+
+[[MESSAGE_CONTEXT]]
+==== Source code context is not shown for errors and warnings detected during bytecode weaving
+
+For compiler errors and warnings detected during bytecode weaving,
+source code context will not be displayed. In particular, for declare
+error and declare warning statements, the compiler now only emits the
+file and line. We are investigating ways to overcome this in cases where
+the source code is available; in cases where source code is not
+available, we might specify the signature of the offending code. For
+more information, see bug 31724.
+
+[[XLINT]]
+==== The -Xlint option
+
+`-Xlint:ignore,error,warning` will set the level for all Xlint warnings.
+`-Xlint`, alone, is an abbreviation for `-Xlint:warning`.
+
+The `-Xlintfile:lint.properties` allows fine-grained control. In
+tools.jar, see `org/aspectj/weaver/XlintDefault.properties` for the
+default behavior and a template to copy.
+
+More `-Xlint` warnings are supported now, and we may add disabled
+warnings in subsequent bug-fix releases of 1.1. Because the
+configurability allows users to turn off warnings, we will be able to
+warn about more potentially dangerous situations, such as the
+potentially unsafe casts used by very polymorphic uses of proceed in
+around advice.
+
+[[NO_SOURCE]]
+==== Source-specific options
+
+Because AspectJ 1.1 does not generate source code after weaving, the
+source-code-specific options -preprocess, -usejavac, -nocomment and
+-workingdir options are meaningless and so not supported.
+
+[[NO_STRICT_LENIENT]]
+==== The -strict and -lenient options
+
+Because AspectJ 1.1 uses the Eclipse compiler, which has its own
+mechanism for changing strictness, we no longer support the -strict and
+-lenient options.
+
+[[NO_PORTING]]
+==== The -porting option
+
+AspectJ 1.1 does not have a -porting option.
+
+[[_13_REQUIRED]]
+==== J2SE 1.3 required
+
+Because we build on Eclipse, the compiler will no longer run under J2SE
+1.2. You must run the compiler (and all tools based on the compiler)
+using J2SE 1.3 or later. The code generated by the compiler can still
+run on Java 1.1 or later VM's if compiled against the correct runtime
+libraries.
+
+[[DEFAULT_CONSTRUCTOR_CONFLICT]]
+==== Default constructors
+
+AspectJ 1.1 does not allow the inter-type definition of a zero-argument
+constructor on a class with a visible default constructor. So this is no
+longer allowed:
+
+[source, java]
+....
+class C {}
+
+aspect A {
+    C.new() {}  // was allowed in 1.0.6
+                // is a "multiple definitions" conflict in 1.1
+}
+....
+
+In the Java Programming Language, a class defined without a constructor
+actually has a "default" constructor that takes no arguments and just
+calls `super()`.
+
+This default constructor is a member of the class like any other member,
+and can be referenced by other classes, and has code generated for it in
+classfiles. Therefore, it was an oversight that AspectJ 1.0.6 allowed
+such an "overriding" inter-type constructor definition.
+
+[[SUPER_IFACE_INITS]]
+==== Initialization join points for super-interfaces
+
+In AspectJ, interfaces may have non-static members due to inter-type
+declarations. Because of this, the semantics of AspectJ defines the
+order that initializer code for interfaces is run.
+
+In the semantics document for AspectJ 1.0.6, the following promises were
+made about the order of this initialization:
+
+. a supertype is initialized before a subtype
+. initialized code runs only once
+. initializers for supertypes run in left-to-right order
+
+The first two properties are important and are preserved in AspectJ 1.1,
+but the third property is and was ludicrous, and was never properly
+implemented (and never could be) in AspectJ 1.0.6. Consider:
+
+[source, java]
+....
+interface Top0 {}
+interface Top1 {}
+interface I extends Top0, Top1 {}
+interface J extends Top1, Top0 {}
+
+class C implements I, J {}
+// I says Top0's inits must run before Top1's
+// J says Top1's inits must run before Top0's
+
+aspect A {
+    int Top0.i = foo("I'm in Top0");
+    int Top1.i = foo("I'm in Top1");
+    static int foo(String s) {
+        System.out.println(s);
+        return 37;
+    }
+}
+....
+
+This was simply a bug in the AspectJ specification. The correct third
+rule is:
+
+____
+the initializers for a type's superclass are run before the initializers
+for its superinterfaces.
+____
+
+[[VOID_FIELD_SET]]
+==== Field Set Join Points
+
+In AspectJ 1.0.6, the join point for setting a field F had, as a return
+type, F's type. This was "java compatible" because field assignment in
+java, such as "Foo.i = 37", is in fact an expression, and does in fact
+return a value, the value that the field is assigned to.
+
+This was never "java programmer compatible", however, largely because
+programmers have absorbed the good style of rarely using an assignment
+statement in a value context. Programmers typically expect "Foo.i = 37"
+not to return a value, but to simply assign a value.
+
+Thus, programmers typically wanted to write something like:
+
+[source, java]
+....
+void around(): set(int Foo.i) {
+    if (theSetIsAllowed()) {
+        proceed();
+    }
+}
+....
+
+And were confused by it being a compile-time error. They weren't
+confused for long, and soon adapted to writing:
+
+[source, java]
+....
+int around(): set(int Foo.i) {
+    if (theSetIsAllowed()) {
+        return proceed();
+    } else {
+        return Foo.i;
+    }
+}
+....
+
+But there was definitely a short disconnect.
+
+On top of that, we were never shown a convincing use-case for returning
+an interesting value from a set join point. When we revisited this
+issue, in fact, we realized we had a long-standing bug in 1.0.6 dealing
+with the return value of pre-increment expressions (such as ++Foo.i)
+that nobody had found because nobody cares about the return value of
+such join points.
+
+So, because it's easier to implement, and because we believe that this
+is the last possibility to make the semantics more useful, we have made
+set join points have a void return type in 1.1.
+
+[[XNOINLINE]]
+==== The -XnoInline Option
+
+The `-XnoInline` option to indicate that no inlining of any kind should
+be done. This is purely a compiler pragma: No program semantics (apart
+from stack traces) will be changed by the presence or absence of this
+option.
+
+[[TARGET_TYPES_MADE_PUBLIC]]
+==== Target types made public
+
+Even in 1.0.6, the AspectJ compiler has occasionally needed to convert
+the visibility of a package-level class to a public one. This was
+previously done in an ad-hoc basis that took whole-program analysis into
+account. With the incremental compilation model of AspectJ 1.1, we can
+now specify the occasions when the compiler makes these visibility
+changes.
+
+In particular, the types used in the `this`, `target`, and `args`
+pointcuts are made public, as are the super-types from `declare parents`
+and the exception type from `declare soft`.
+
+We believe the visibility changes could be avoided in the future with
+various implementation tricks if they become a serious concern, but did
+not encounter them as such a concern when they were done in the 1.0.6
+implementation.
+
+[[STRINGBUFFER]]
+==== String + now advised
+
+In Java, the + operator sometimes results in StringBuffer objects being
+created, appended to, and used to generate a new String. Thus,
+
+[source, java]
+....
+class Foo {
+    String makeEmphatic(String s) {
+        return s + "!";
+    }
+}
+....
+
+is approximately the same at runtime as
+
+[source, java]
+....
+class Foo {
+    String makeEmphatic(String s) {
+        return new StringBuffer(s).append("!").toString();
+    }
+}
+....
+
+In the design process of AspectJ 1.0.6 we didn't expose those
+StringBuffer methods and constructors as join points (though we did
+discuss it), but in 1.1 we do.
+
+This change is likely to affect highly wildcarded aspects, and can do so
+in surprising ways. In particular:
+
+[source, java]
+....
+class A {
+    before(int i): call(* *(int)) && args(i) {
+        System.err.println("entering with " + i);
+    }
+}
+....
+
+may result in a stack overflow error, since the argument to println is
+really
+
+[source, java]
+....
+new StringBuffer("entering with ").append(i).toString()
+....
+
+which has a call to StringBuffer.append(int). In such cases, it's worth
+restricting your pointcut, with something like one of:
+
+[source, java]
+....
+call(* *(int)) && args(i) && !within(A)
+call(* *(int)) && args(i) && !target(StringBuffer)
+....
+
+[[ONE_FOUR_METHOD_SIGNATURES]]
+==== The -1.4 flag and method signatures
+
+Consider the following aspect
+
+[source, java]
+....
+public aspect SwingCalls {
+
+    pointcut callingAnySwing(): call(* javax.swing..*+.*(..));
+
+    before(): callingAnySwing() {
+        System.out.println("Calling any Swing");
+    }
+}
+....
+
+And then consider the two statements
+
+[source, java]
+....
+JFrame frame = new JFrame();
+frame.setTitle("Title");
+....
+
+According to the Java Language Specification version 2, the call to
+`frame.setTitle("Title")` should always produce the bytecode for a call
+to `javax.swing.JFrame.setTitle`. However, older compilers (and eclipse
+when run without the `-1.4` flag) will generate the bytecode for a call
+to `java.awt.Frame.setTitle` instead since this method is not overriden
+by JFrame. The AspectJ weaver depends on the correctly generated
+bytecode in order to match patterns like the one you show correctly.
+
+This is a good example of why the pattern
+`call(* *(..)) && target(JFrame)` is the recommended style. In general,
+OO programmers don't want to care about the static type of an object at
+a call site, but only want to know the dynamic instanceof behavior which
+is what the target matching will handle.
+
+[[knownLimitations]]
+=== Known limitations
+
+The AspectJ 1.1.0 release contains a small number of known limitations
+relative to the AspectJ 1.1 language. For the most up-to-date
+information about known limitations in an AspectJ 1.1 release, see the
+bug database at https://bugs.eclipse.org/bugs, especially the open bugs
+for the
+https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Compiler&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED[compiler],
+https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=IDE&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED[IDE
+support],
+https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Doc&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED[documentation],
+and
+https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Ant&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED[Ant
+tasks]. Developers should know about bugs marked with the "info" keyword
+because those bugs reflect failures to implement the 1.1 language
+perfectly. These might be fixed during the 1.1 release cycle; find them
+using the query
+https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&keywords=info
+For ajc's 1.1 implementation limitations, see
+link:progguide/implementation.html[Programming Guide Appendix:
+"Implementation Notes"].
diff --git a/docs/dist/doc/README-1.2.1.adoc b/docs/dist/doc/README-1.2.1.adoc
new file mode 100644
index 000000000..04cb6e831
--- /dev/null
+++ b/docs/dist/doc/README-1.2.1.adoc
@@ -0,0 +1,134 @@
+== AspectJ 1.2.1
+
+_© Copyright 2004 Contributors. All rights reserved._
+
+AspectJ 1.2.1 is largely a bug-fix release and the definition of the
+AspectJ language is unchanged from the 1.2.0 release (with the exception
+that AspectJ 1.2.1 permits the use of the '+' operator to concatenate
+the messages for declare error and warning statements). This document
+describes the tools differences between AspectJ versions 1.2 and 1.2.1.
+Users familiar with AspectJ 1.2 may find this document a quicker way to
+learn what changed in the tools.
+
+This document summarizes changes in:
+
+* Weaver messages
+* Dump support
+* JDT Compiler version
+* Line number information for join points
+* Runtime performance
+* String concatentation in declare error and warning statements
+* Load-time weaving support
+* Use of aspect libraries generated by ajc 1.2.1 with earlier versions
+of ajc
+
+See the link:changes.html[changes document] for more details, or
+xref:#allchanges[all the changes] as detailed in the bugzilla database.
+
+=== Weaver Informational Messages
+
+The AspectJ 1.2.1 compiler can produce informational messages about the
+weaving process. To see these messages, use the -showWeaveInfo compiler
+option, or set showweaveinfo=true in the iajc ant task.
+
+The following is an example of the messages produced when this option is
+enabled:
+
+[source, text]
+....
+C:\aspectj1.2.1\doc\examples\tjp>ajc -showWeaveInfo *.java
+
+Type 'tjp.Demo' (Demo.java:20) advised by around advice from 'tjp.GetInfo'
+(GetInfo.java:26) [RuntimeTest=true]
+
+Type 'tjp.Demo' (Demo.java:30) advised by around advice from 'tjp.GetInfo'
+(GetInfo.java:26) [RuntimeTest=true]
+
+Type 'tjp.Demo' (Demo.java:34) advised by around advice from 'tjp.GetInfo'
+(GetInfo.java:26) [RuntimeTest=true]
+....
+
+=== Dump Support
+
+In the event of a compiler crash, AspectJ 1.2.1 will produce a dump file
+giving important information about the state of the compiler at the time
+of the crash. These dump files should enable us to analyze problems more
+effectively. In the rare event that you witness a compiler crash, please
+attach the dump file to the bug report.
+
+In addition to producing a dump file when an abort condition is
+detected, the AspectJ 1.2.1 compiler can also be requested to create a
+dump file on detection of a compilation error. Set the property
+org.aspectj.weaver.Dump.condition=error to enable this behaviour.
+
+=== JDT Compiler Version
+
+AspectJ 1.2.1 is based on the Eclipse 3.0 final JDT compiler.
+
+=== Line Number Information for Join Points
+
+For source files compiled by ajc (as opposed to binary inputs to the
+compiler compiled with some other java compiler), ajc now emits better
+line number information for execution join points. In particular, for a
+method, constructor or advice execution join point (as matched for
+example by a declare error or declare warning statement), ajc 1.2.1
+reports the first line number of the declaration, as opposed to the line
+number of the first line of code in the body.
+
+=== Runtime Performance
+
+AspectJ 1.2.1 contains a small number of runtime performance
+optimisations, including optimisations of if(true) and if(false)
+pointcut expressions, caching of getSignature() and toString() results
+on JoinPoint objects, and an optimised implementation of cflow.
+
+In the case where there are no arguments bound in the cflow pointcut,
+programs compiled under AspectJ 1.2.1 and that make heavy use of cflow
+will run significantly faster. Thanks to the abc compiler team for
+detecting this performance related bug and for piloting the fix.
+
+=== String Concatentation in Declare Error/Warning Statements
+
+String concatentation in declare error and warning statements is now
+supported. For example, you can write:
+
+[source, java]
+....
+declare warning : jdbcCall() && !inDataLayer()
+                : "Please don't make calls to JDBC " +
+                  "outside of the data layer.";
+....
+
+=== Load-time Weaving Support
+
+The AspectJ 1.2.1 distribution contains a new jar in the lib directory,
+aspectjweaver.jar, that contains the subset of aspectjtools.jar needed
+for weaving only. This jar may be used in situations where you wish to
+exploit AspectJ's binary weaving capabilities, but do not want the full
+aspectjtools.jar around (aspectjweaver.jar is approx. 5 times smaller).
+
+In addition, the load-time weaving "aj" script which was included in the
+doc/examples/ltw directory in the 1.2 distribution has been moved into
+the regular bin directory. See xref:README-1.2.adoc[README-1.2] for
+details of using this script.
+
+=== Binary Compatibility
+
+AspectJ 1.2.1 introduces a backwards-incompatible change to the class
+file format generated by the AspectJ compiler. Classes generated by ajc
+v1.2.1 cannot be used on the inpath or aspectpath of a weaver from a
+prior version of the compiler. Classes generated by prior versions of
+the compiler can of course be placed on the inpath or aspectpath of the
+1.2.1 weaver.
+
+As ever, you should use the AspectJ runtime library (aspectjrt.jar) that
+comes with the distribution you used to build your application.
+
+'''''
+
+[[allchanges]]
+=== All changes are listed in the bug database
+
+For a complete list of changes in the 1.2.1 release, search for
+`target 1.2.1` in the bug database:
+https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Compiler&target_milestone=1.2.1[https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&target_milestone=1.2.1&bug_status=RESOLVED&resolution=FIXED]
diff --git a/docs/dist/doc/README-1.2.adoc b/docs/dist/doc/README-1.2.adoc
new file mode 100644
index 000000000..0cbc3b93c
--- /dev/null
+++ b/docs/dist/doc/README-1.2.adoc
@@ -0,0 +1,568 @@
+== AspectJ 1.2
+
+_© Copyright 2003,2004 Contributors. All rights reserved._
+
+The definition of the AspectJ language is unchanged in the 1.2 release.
+Instead, AspectJ 1.2 provides major improvements to the functionality of
+the supporting tools and enforces some language limits that went
+unchecked before. This document describes the tools differences between
+AspectJ versions 1.2 and 1.1.1. Users new to AspectJ need only read the
+link:progguide/index.html[AspectJ Programming Guide] since it describes
+the 1.2 language. Users familiar with AspectJ 1.1 may find this document
+a quicker way to learn what changed in the tools, and should use it as a
+guide for porting programs from 1.1 to 1.2, together with porting.html.
+
+This document first summarizes changes from the 1.1.1 release in
+
+* xref:#compiler[the compiler],
+* xref:#tools[the support tools],
+* xref:#runtime[the runtime],
+* xref:#devenv[the development environment support],
+
+then xref:#details[details] some of the changes, and finally points
+readers to the bug database for xref:#allchanges[all the changes].
+
+'''''
+
+[[compiler]]
+=== The Compiler
+
+Compared to AspectJ 1.1.1, the AspectJ 1.2 compiler...
+
+* xref:#WEAVE_TIME[Is faster], with weaving completing in less than half
+the time it used to take in many cases.
+[#WEAVE_CHART]#image:images/AspectJ11v12.JPG[image]#.
+* Supports the xref:#LAZY_TJP[-XlazyTjp option] which produces code that
+runs faster and uses less memory in some common cases.
+* Has xref:#INCREMENTAL[much better support for incremental
+compilation].
+* Produces xref:#ERROR_MESSAGES[better error messages].
+* Has some xref:#LINT[new lint warnings] to catch common mistakes and
+changes to serializability.
+* Supports the xref:#REWEAVABLE[-Xreweavable option] that allows classes
+to be woven more than once.
+* {blank}
+* Supports the xref:#INPATH[-inpath option] which allows both
+directories and jars containing class files to be specified as input to
+the weaver.
+* xref:#COMPLIANCE[Changes the default compiler compliance mode] from
+-1.3 to -1.4.
+
+A short description of the options ajc accepts is available with
+"`ajc -help`". Longer descriptions are available in the
+link:devguide/ajc-ref.html[Development Environment Guide section on
+ajc].
+
+'''''
+
+[[tools]]
+=== Support Tools
+
+AspectJ 1.2 contains two important changes to the supporting tools:
+
+* xref:#AJDOC[ajdoc] is back
+* A sample script is supplied for xref:#LTW[load-time weaving] from the
+command-line.
+
+'''''
+
+[[runtime]]
+=== The Runtime Library
+
+This release has minor updates to the runtime library classes. As with
+any release, you should compile and run with the runtime library that
+came with your compiler, and you may run with a later version of the
+library without recompiling your code.
+
+* xref:#SOFTEX[`SoftException`] now supports `getCause()`.
+* Although not part of `aspectjrt.jar` this release also provides a new
+set of tools APIs in the xref:#LTW2[`org.aspectj.weaver.tools`] that
+provide a weaving class loader and an adapter that can be used to
+integrate load-time weaving into an existing class loader hierarchy.
+* Cflow stack management has been modified to use thread local storage
+on JVMs that support this feature. This improves performance in terms of
+heap usage for multi-threaded applications that use cflow.
+
+'''''
+
+[[devenv]]
+=== The AJDE Tools
+
+The AJDE based tools for JBuilder, NetBeans and Emacs continue to be
+independent SourceForge projects. The AspectJ 1.2 distribution includes
+an updated version of the AjBrowser tool that benefits from all the
+enhancements made in the 1.2 compiler.
+
+The 1.2 release of AspectJ also lays a lot of the groundwork for a much
+better AspectJ IDE experience that we hope to surface initially through
+AJDT (AspectJ support for Eclipse). Amongst the many improvements, we
+will have full eager parsing support that avoids the need to keep the
+whole structure model of a project in memory, hopefully making AJDT much
+less memory hungry and much slicker to use. For more details see the
+https://www.eclipse.org/ajdt[AJDT project website].
+
+'''''
+
+[[details]]
+=== Details of some compiler changes
+
+[[WEAVE_TIME]]
+==== Compilation (weave) times reduced.
+
+Our benchmark suite shows that AspectJ 1.2 is at least twice as fast in
+the weaving phase as AspectJ 1.1.1 for matches based on a variety of
+pointcut expressions (see the xref:#WEAVE_CHART[chart above]). We've
+also made the base incremental compilation implementation in AspectJ 1.2
+approximately twice as fast as in AspectJ 1.1.1, so when this is
+combined with the weave time improvements you should see speed-ups of up
+to 4x for incremental compilation.
+
+In addition, AspectJ 1.2 maintains only weak references to some of its
+recoverable data structures, allowing the JVM to optimise between
+performance and memory usage. Experiments forcing GC showed that we can
+achieve about a 20% memory usage reduction in this manner if needed.
+
+[[LAZY_TJP]]
+==== The -XlazyTjp option.
+
+Under AspectJ 1.1.1, if the body of an advice contained a reference to a
+non-statically determinable portion of `thisJoinPoint` (such as for
+example a call to `getArgs()`), then a JoinPoint object was always
+creating before entering the advice. This was the case even if the
+advice was guarded with an `if()` pointcut that evaluated to false.
+
+AspectJ 1.2 now supports the `-XlazyTjp` option that only creates the
+JoinPoint object just before dispatching to the advice body. By
+promoting the guard to a test in an `if()` pointcut, the creation of the
+JoinPoint object can be avoided altogether in the case where the test
+returns false.
+
+Consider a simple tracing aspect as follows:
+
+[source, java]
+....
+public aspect Tracing {
+
+  public static boolean enabled = false;
+
+  pointcut toBeTraced() : execution(* *(..)) || execution(new(..));
+
+  before() : toBeTraced() && if(enabled) {
+    Object[] args = thisJoinPoint.getArgs();
+    // format args and print out entry trace record etc....
+  }
+}
+....
+
+The most important consideration is the system overhead when tracing is
+turned off. Using the `-XlazyTjp` option makes the program above run
+10-100x faster, even when running a small test case with minimal GC
+issues. The optimization is disabled at join points advised by around
+advice, and an Xlint warning will be displayed in these cases.
+
+[[INCREMENTAL]]
+==== Improvements to incremental compilation.
+
+AspectJ 1.2 provides more complete incremental compilation support than
+AspectJ 1.1.1. Firstly, incremental compilation resulting from a change
+to a source file is now approximately twice as fast as it was under
+1.1.1 (even before taking the improvements to weaving time into
+account). Secondly, the incremental coverage now takes into account
+changes to resources, classes and jars on the inpath, injars, and
+aspectpath. The new `inpath` option in AspectJ 1.2 allows directories to
+be specified in addition to jars (just like a classpath) as input to the
+weaver. Any update, addition or deletion of a class file in a directory
+on the inpath will cause incremental (re)weaving.
+
+Changes to a jar file on the inpath, injars or aspectpath will now be
+detected, but will trigger a full rebuild, as will any change to the
+paths used to control compilation.
+
+[[ERROR_MESSAGES]]
+==== Improved error messages.
+
+AspectJ 1.1.1 did not provide source context information for messages
+produced during the weaving phase, even in the case where source files
+were passed to the compiler. For example, an error message arising as a
+result of a `declare error` statement might look as follows under
+AspectJ 1.1.1:
+
+[source, text]
+....
+BadClass.java:6 should not be calling bad methods
+....
+
+whereas in AspectJ 1.2 you will see:
+
+[source, text]
+....
+BadClass.java:6 error should not be calling bad methods
+new C().bad();
+^^^^^^^^^^^^^^
+     method-call(void C.bad())
+     see also: DeclareError.java:5
+....
+
+There are four new things to note about this error message. Firstly,
+errors and warnings are now prefixed with the word "error", or "warning"
+as appropriate. Secondly, the offending line of source is shown if
+source code is available. Thirdly, in the case of weaver messages
+arising as a result of `declare error` and `declare warning` statements,
+AspectJ now shows not only the location of the error or warning, but
+also the location of the `declare` statement itself. Finally, note that
+messages produced as a result of `declare error` and `declare warning`
+statements now also display the matched join point at the location of
+the error:
+
+When source code is not available, the messages show the binary input
+source (class file or jar file) in which the error or warning was
+detected:
+
+[source, text]
+....
+BadClass.java:6 error should not be calling bad methods
+(no source information available)
+       method-call(void C.bad())
+       see also: C:\...\DeclareError.java:5
+       see also: C:\...\bin-input.jar
+....
+
+This error message tells us that `BadClass.class` contained in a jar on
+the inpath called `bin-input.jar`, and originally compiled from a source
+file called `BadClass.java`, contains a join point
+(`method-call(void C.bad())` matched by a `declare error` statement on
+line 5 of the file `DeclareError.java`.
+
+[[LINT]]
+==== New lint warnings.
+
+Consider the program:
+
+[source, java]
+....
+/*01*/ class A {
+/*02*/   public void doIt() {...};
+/*03*/ }
+/*04*/
+/*05*/ class B extends A {
+/*06*/   public void doThisToo() {...};
+/*07*/ }
+/*08*/
+/*09*/
+/*10*/ public class CallsAandB {
+/*11*/
+/*12*/  public static void main(String[] args) {
+/*13*/    B b = new B();
+/*14*/    A bInDisguise = new B();
+/*15*/
+/*16*/    b.doIt();               // AspectJ 1.2 matches here
+/*17*/    bInDisguise.doIt();     // this is never matched
+/*18*/  }
+/*19*/
+/*20*/ }
+/*21*/
+/*22*/ aspect CallPCDMatchingExample {
+/*23*/
+/*24*/   before() : call(* B.doIt(..)) {
+/*25*/     System.out.println("About to call B.doIt(...)");
+/*26*/   }
+/*27*/
+/*28*/ }
+....
+
+Because the static type of `bInDisguise` is `A` (line 14), the call on
+line 17 is never matched by the pointcut expression on 24, even though
+the runtime type of `bInDisguise` is `B`. Type patterns matched in
+`call` pointcut designators are matched based on static type matching.
+Some users have found this static type matching confusing, and AspectJ
+1.2 has a new Xlint warning (`unmatchedSuperTypeInCall`) which is
+enabled by default.
+
+The compiler will now produce a warning whenever a call pointcut
+designator does not match at a join point, and a user may have expected
+it to. Compiling the above program using AspectJ 1.2 produces the
+following compiler output:
+
+[source, text]
+....
+CallsAandB.java:24 warning does not match because declaring type is A, if match desired use target(B) [Xlint:unmatchedSuperTypeInCall]
+before() : call(* B.doIt(..)) {
+           ^^^^^^^^^^^^^^^
+    see also: CallsAandB.java:17
+
+1 warning
+....
+
+The warning is telling us that the call pointcut associated with the
+before advice on line 24 of the source file does not match at a join
+point where the user may have expected it to. The source location
+corresponding to the unmatched join point is indicated by the "see also"
+line - in this case line 17 of the source file. At line 17 we find a
+call to `bInDisguise.doIt()`. Since the static type of `bInDisguise` is
+`A`, this call will never be matched. The warning also tells us a
+possible solution if we intended the pointcut to match at this join
+point: use `call(* doIt(..) && target(B)`.
+
+If you find warnings of this kind coming out when you use the AspectJ
+1.2 compiler, the recommended fix is to switch to using the `target`
+designator in place of a type pattern in the `call` pointcut expression.
+Note that there is no loss of runtime efficiency here - runtime tests
+are only added in the cases where it cannot be determined at compile
+time whether the type of the receiver will match the type specified in
+the `target` expression. Also note that `target` cannot be used in
+`declare` statements.
+
+A new Xlint warning, `needsSerialVersionUIDField` (disabled by default)
+will produce a warning at compile time if the process of weaving changes
+the default `serialVersionUID` of a serializable class, and the class
+does not define a `serialVersionUID`. By defining a `serialVersionUID`
+field, the programmer can ensure that objects serialized without the
+aspect present can be read by a version of the program in which the
+aspect is present, and vice-versa.
+
+A complimentary Xlint warning, `brokeSerialVersionCompatibility`
+(disabled by default) will produce a warning at compile time if the
+process of weaving makes an incompatible change to a serializable class
+(for example, through the addition of an inter-type declared field).
+
+[[REWEAVABLE]]
+==== The -Xreweavable option.
+
+The new `-Xreweavable` option produces class files that contain enough
+additional information in them that they can be rewoven. In time we hope
+that this can become a standard option, replacing the current
+`-Xnoweave` option. Using reweavable produces class files that can be
+legally loaded by a JVM, whereas with noweave, it is too easy to produce
+class files that will result in a verify error at runtime. The
+reweavable option makes it easy to weave code many times without having
+to decide which weave is the final one. In a future version of the
+AspectJ compiler, producing reweavable class files may become the
+default option. The trade-off at the moment is that reweavable class
+files are currently approximately twice the size of their non-reweavable
+counterparts.
+
+To ensure consistent semantics when reweaving, the AspectJ compiler
+requires that all aspects that have previously modified a class file
+during weaving be present in the system during a reweave. An error will
+be issued if any are missing.
+
+[[INPATH]]
+==== The -inpath option.
+
+The new `-inpath` option replaces the `-injars` option (which is still
+supported for backwards compatibility). It allows both directories and
+jar files to be specified using path separators to separate entries in
+the path. This option makes it easy for class files produced as the
+result of building one project to become binary input to the compilation
+of a second project.
+
+[[COMPLIANCE]]
+==== The default compliance mode of the compiler has changed from -1.3 to -1.4.
+
+The default AspectJ compiler compliance level is now 1.4 (whereas in
+previous releases the default compliance level was 1.3). This has a
+number of implications:
+
+* class files generated by the compiler are now JRE v1.2 and upwards
+compatible. (At compliance level 1.3, AspectJ generated class files that
+were compatible with JRE 1.1 also).
+* `call` pointcuts may match more join points than in the same program
+compiled at compliance level 1.3.
+
+The AspectJ compiler can be restored to 1.3 compliance settings by
+specifying the "-1.3" option on the command-line.
+
+Consider again the following example program which illustrates the
+differences in join point matching with the `call` pointcut designator
+between 1.4 and 1.3 compliance levels.
+
+[source, java]
+....
+/*01*/ class A {
+/*02*/   public void doIt() {...};
+/*03*/ }
+/*04*/
+/*05*/ class B extends A {
+/*06*/   public void doThisToo() {...};
+/*07*/ }
+/*08*/
+/*09*/
+/*10*/ public class CallsAandB {
+/*11*/
+/*12*/  public static void main(String[] args) {
+/*13*/    B b = new B();
+/*14*/    A bInDisguise = new B();
+/*15*/
+/*16*/    b.doIt();               // AspectJ 1.2 matches here
+/*17*/    bInDisguise.doIt();     // this is never matched
+/*18*/  }
+/*19*/
+/*20*/ }
+/*21*/
+/*22*/ aspect CallPCDMatchingExample {
+/*23*/
+/*24*/   before() : call(* B.doIt(..)) {
+/*25*/     System.out.println("About to call B.doIt(...)");
+/*26*/   }
+/*27*/
+/*28*/ }
+....
+
+When this program is compiled with AspectJ 1.2 using the default
+compiler options, it will produce one line of output when it is
+executed:
+
+`About to call B.doIt(...)`
+
+The same program compiled under AspectJ 1.1 (or using AspectJ 1.2 with
+the -1.3 flag specified) does not produce any output when it is run. The
+reason for the additional call pcd match is that prior to compliance
+level 1.4, Java compilers produced bytecodes that call A.doIt() (the
+defining type of the method), rather than B.doIt() (the declared type in
+the program text). The generated call to A.doIt() is not matched by the
+call pcd used in the before advice. At compliance level 1.4, the
+bytecodes retain the declared type of the receiver in the program
+source, generating a call to B.doIt(), which _is_ matched by the call
+pcd.
+
+This is a good example of why the recommended style is to use
+`call(* doIt(..)) && target(B)`, which always matches based on the
+actual type of the receiver.
+
+'''''
+
+[[AJDOC]]
+==== The ajdoc tool makes a comeback in the AspectJ 1.2 distribution.
+
+`ajdoc` (the AspectJ replacement for the `javadoc` tool) is once again
+included in the AspectJ distribution. The `ajdoc` tool produces regular
+javadoc that also shows advises and advised by relationships next to
+methods and advice. A future enhancement will show inter-type
+declarations in the target class too.
+
+*Known limitations:* Please note that `ajdoc` documents advice and
+pointcut members, shows where advice applies and links affected members
+back to the advice.  It currently does not document or add structural
+links for any inter-type declarations or other declare forms.
+
+Run the "ajdoc.bat" script just as you run javadoc.  For a list of
+accepted parameters run "ajdoc -help".  For example, to document
+everything in the Spacewar example run: +
+> cd examples +
+> ajdoc -d doc -private spacewar coordination
+
+`ajdoc` sample output for an aspect source file:
+
+image:images/ajdoc1.JPG[image]
+
+`ajdoc` sample output for advised methods:
+
+image:images/ajdoc2.JPG[image]
+
+[[LTW]]
+==== A sample script is supplied that supports load-time weaving from the command-line
+
+The AspectJ 1.2 distribution ships with sample scripts for Windows and
+Unix platforms that exploit AspectJ's binary weaving capabilities at
+application load time. You will find these scripts in the
+`doc/examples/ltw` directory of your AspectJ installation.
+
+The scripts allow you to set an environment variable, `ASPECTPATH`,
+containing a path-separator delimited list of aspect-library jar files.
+A Java application can then be launched using the "`aj`" script ("`aj`"
+is to "`ajc`" as "`java`" is to "`javac`"). If the `ASPECTPATH` is unset
+or empty, "`aj`" behaves exactly the same as "`java`", but if the
+`ASPECTPATH` contains one or more aspect libraries, the aspects in the
+library will be linked (woven) with the application code as it is
+loaded.
+
+The `doc/examples/ltw` directory of your AspectJ installation contains a
+sample application that demonstrates these capabilities. Following the
+instructions in the `README` file in that directory, running
+"`aj tracing.ExampleMain`" with `ASPECTPATH` unset produces the output:
+
+[source, text]
+....
+c1.perimeter() = 12.566370614359172
+c1.area() = 12.566370614359172
+s1.perimeter() = 4.0
+s1.area() = 1.0
+c2.distance(c1) = 4.242640687119285
+s1.distance(c1) = 2.23606797749979
+s1.toString(): Square side = 1.0 @ (1.0, 2.0)
+....
+
+If you set `ASPECTPATH` to include `../jars/tracingLib.jar`, and run
+"`aj tracing.ExampleMain`" again, the output will be:
+
+[source, text]
+....
+  --> tracing.TwoDShape(double, double)
+  <-- tracing.TwoDShape(double, double)
+  --> tracing.Circle(double, double, double)
+  <-- tracing.Circle(double, double, double)
+  --> tracing.TwoDShape(double, double)
+  <-- tracing.TwoDShape(double, double)
+  --> tracing.Circle(double, double, double)
+  <-- tracing.Circle(double, double, double)
+  --> tracing.Circle(double)
+  <-- tracing.Circle(double)
+  --> tracing.TwoDShape(double, double)
+  <-- tracing.TwoDShape(double, double)
+  --> tracing.Square(double, double, double)
+  <-- tracing.Square(double, double, double)
+  --> tracing.Square(double, double)
+  <-- tracing.Square(double, double)
+  --> double tracing.Circle.perimeter()
+  <-- double tracing.Circle.perimeter()
+c1.perimeter() = 12.566370614359172
+  --> double tracing.Circle.area()
+  <-- double tracing.Circle.area()
+c1.area() = 12.566370614359172
+  --> double tracing.Square.perimeter()
+  <-- double tracing.Square.perimeter()
+s1.perimeter() = 4.0
+  --> double tracing.Square.area()
+  <-- double tracing.Square.area()
+s1.area() = 1.0
+  --> double tracing.TwoDShape.distance(TwoDShape)
+    --> double tracing.TwoDShape.getX()
+    <-- double tracing.TwoDShape.getX()
+    --> double tracing.TwoDShape.getY()
+    <-- double tracing.TwoDShape.getY()
+  <-- double tracing.TwoDShape.distance(TwoDShape)
+  etc...
+....
+
+The scripts only support JDK 1.4 and above - attempting to use them with
+a 1.3 or lower JDK will most likely produce `NoClassDefFound` errors. We
+welcome contributions from users to improve these scripts.
+
+'''''
+
+[[SOFTEX]]
+==== SoftException now supports getCause()
+
+`org.aspectj.lang.SoftException` now supports the `getCause()` method,
+which returns the original exception wrapped by the `SoftException`.
+This means that exception chains will print correctly on 1.4 and later
+JREs.
+
+[[LTW2]]
+==== org.aspectj.weaver.tools package added
+
+A new set of public APIs are exported by the
+link:api/index.html[`org.aspectj.weaver.tools`] package that can be used
+to integrate load-time weaving into an existing class loader hierachy.
+The package implementation is included in `aspectjtools.jar`. For an
+example of how to use these APIs, see the
+`org.aspectj.weaver.WeavingURLClassLoader` implementation.
+
+'''''
+
+[[allchanges]]
+=== All changes are listed in the bug database
+
+For a complete list of changes in the 1.2 release, search for
+`target 1.2` in the bug database:
+https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Compiler&target_milestone=1.2
diff --git a/docs/dist/doc/README-1.5.0.adoc b/docs/dist/doc/README-1.5.0.adoc
new file mode 100644
index 000000000..e3f7c1196
--- /dev/null
+++ b/docs/dist/doc/README-1.5.0.adoc
@@ -0,0 +1,19 @@
+== AspectJ 5
+
+_© Copyright 2005 Contributors. All rights reserved._
+
+AspectJ 5 introduces several important changes to the language and tools
+in order to support Java 5 and extend the capabilities of AspectJ in
+general. For language changes, see xref:../../adk15notebook/adk15notebook.adoc[AspectJ 5 Developer's Notebook]. For tools changes, see the
+link:devguide/index.html[AspectJ Development Environment Guide],
+especially the section on link:devguide/ltw.html[Load-time weaving]. The
+changes are summarized in the faq.html#q:aspectj5features[FAQ entry on
+AspectJ 5].
+
+Some of the other documentation has not been updated for AspectJ 5. For
+the latest documentation, see
+https://eclipse.org/aspectj/doc/next/index.html, linked off
+https://eclipse.org/aspectj/docs.php[the AspectJ documentation home page].
+
+For information on bug fixes in AspectJ 5 v1.5.0, see the
+link:changes.html[changes] document.
diff --git a/docs/dist/doc/README-1.5.1.adoc b/docs/dist/doc/README-1.5.1.adoc
new file mode 100644
index 000000000..bc513d512
--- /dev/null
+++ b/docs/dist/doc/README-1.5.1.adoc
@@ -0,0 +1,22 @@
+== AspectJ 5 v1.5.1 Readme
+
+_© Copyright 2006 Contributors. All rights reserved._
+
+This release is primarily a bug fix and performance / memory usage
+release. Over 70 fixes and enhancements have been incorporated since
+1.5.0, you can see the list through
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=AspectJ&target_milestone=1.5.1&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED[this
+bugzilla query].
+
+AspectJ 1.5.1 has significantly lower memory usage than AspectJ 1.5.0,
+especially when building inside of AJDT. The improvements are also
+noticeable when batch building with Ant, or when load-time weaving.
+Batch building a project with over 1000 source files with both AspectJ
+1.5.1 and AspectJ 1.5.0 shows a 16% reduction in peak memory usage, and
+an 8% reduction in heap consumed by temporary objects. The AspectJ 1.5.1
+compiler integrated into AJDT gives memory savings of at least 50%. The
+greater savings in the AJDT environment are due to improvements in areas
+such as structure model generation that are not exercised
+
+For information on bug fixes in AspectJ 5 v1.5.1, see the
+link:changes.html[changes] document.
diff --git a/docs/dist/doc/README-1.5.2.adoc b/docs/dist/doc/README-1.5.2.adoc
new file mode 100644
index 000000000..b903a9841
--- /dev/null
+++ b/docs/dist/doc/README-1.5.2.adoc
@@ -0,0 +1,30 @@
+== AspectJ 5 v1.5.2 Readme
+
+_© Copyright 2006 Contributors. All rights reserved._
+
+This release is primarily a bug fix release. It includes approximately
+60 fixes and enhancements that have been incorporated since the 1.5.1
+release. You can see the full list through
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=AspectJ&target_milestone=1.5.2&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED[this
+bugzilla query].
+
+Notable changes since the 1.5.1 release include:
+
+* https://bugs.eclipse.org/bugs/show_bug.cgi?id=126167[[_126167]] The
+handling of proceed in @Around advice has changed to be more compatible
+with code style.
+* https://bugs.eclipse.org/bugs/show_bug.cgi?id=147711[[_147711]] Members
+generated as a result of the AspectJ weaving process are now marked Java
+synthetic - enabling coverage tools such as Emma to process woven
+classes correctly.
+* https://bugs.eclipse.org/bugs/show_bug.cgi?id=138316[[_138316]] AspectJ
+has now transitioned from the CPL to the EPL license.
+* https://bugs.eclipse.org/bugs/show_bug.cgi?id=140695[[_140695]] Using a
+more optimal world for managing types when load-time weaving - reduces
+heap usage (work in progress).
+* https://bugs.eclipse.org/bugs/show_bug.cgi?id=101983[[_101983]] AspectJ
+can now support separate output folders for each input source folder -
+enables AJDT to behave more like JDT.
+
+For information on bug fixes in AspectJ 5 v1.5.2, see the
+link:changes.html[changes] document.
diff --git a/docs/dist/doc/README-1.5.3.adoc b/docs/dist/doc/README-1.5.3.adoc
new file mode 100644
index 000000000..d5d9a228c
--- /dev/null
+++ b/docs/dist/doc/README-1.5.3.adoc
@@ -0,0 +1,120 @@
+== 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.
diff --git a/docs/dist/doc/README-1.5.4.adoc b/docs/dist/doc/README-1.5.4.adoc
new file mode 100644
index 000000000..7c8fa50cc
--- /dev/null
+++ b/docs/dist/doc/README-1.5.4.adoc
@@ -0,0 +1,16 @@
+== AspectJ 5 v1.5.4 Readme
+
+_© Copyright 2006 Contributors. All rights reserved._
+
+This release includes a number of bug fixes and enhancements. 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.4&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].
+
+Some key fixes include better handling of generic type declarations,
+both in regular Java classes and in combination with AspectJ constructs
+(for example, inter-type declarations)
+
+ +
+
+'''''
diff --git a/docs/dist/doc/README-1.6.0.adoc b/docs/dist/doc/README-1.6.0.adoc
new file mode 100644
index 000000000..5e37c8efb
--- /dev/null
+++ b/docs/dist/doc/README-1.6.0.adoc
@@ -0,0 +1,172 @@
+== AspectJ 1.6.0
+
+_© Copyright 2008 Contributors. All rights reserved._
+
+=== AspectJ v1.6.0 - 23 Apr 2008
+
+For the complete list of every issue addressed since the last full
+release, see
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.0+M1&target_milestone=1.6.0+M2&target_milestone=1.6.0+RC1&target_milestone=1.6.0&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 link].
+
+Some of the highlights of 1.6.0 are:
+
+==== Upgrade to a Java 1.6 compiler
+
+AspectJ1.6.0 upgrades the internal Eclipse compiler level to version
+785_R33x - a Java 1.6 level compiler
+
+==== Better incremental compilation support in the IDE
+
+Changes under https://bugs.eclipse.org/bugs/show_bug.cgi?id=221427[bug
+221427] mean that the compiler is better able to maintain incremental
+state for projects in Eclipse and determine whether full builds or
+incremental builds are required when project dependencies change. The
+result is that the compiler will more frequently do an incremental build
+rather than falling back to doing a full build. Some basic performance
+findings can be seen in
+https://dev.eclipse.org/mhonarc/lists/aspectj-users/msg09002.html[this
+mailing list post].
+
+==== Parameter annotation matching
+
+Parameter matching is possible for constructors and methods. The use of
+parentheses around the parameter types in a method signature determine
+whether the annotations relate to the type of the parameter or the
+parameter itself.
+
+[source, java]
+....
+execution(* *(@A *));
+....
+
+- Execution of a method/ctor whose first parameter is of a type
+annotated with @A.
+
+[source, java]
+....
+execution(* *(@A (*)));
+....
+
+- Execution of a method/ctor whose first parameter is annotated with @A
+
+[source, java]
+....
+execution(* *(@A (@B *)))
+....
+
+- Execution of a method/ctor whose first parameter is annotated with @A
+and is of a type annotated with @B. Example:
+
+[source, java]
+....
+// ------ Start of Test.java -----
+@interface A {}
+@interface B {}
+
+class C {
+ public void foo(@A String s) {}
+ public void goo(@A @B String s) {}
+}
+
+aspect X {
+ before(): execution(* *(@A (*))) {}
+ before(): execution(* *(@B (*))) {}
+}
+// ------ End of Test.java -----
+....
+
+[source, text]
+....
+$ ajc -showWeaveInfo -1.6 Test.java
+Join point 'method-execution(void C.foo(java.lang.String))' in Type 'C' (A.java:5) advised by before advice from 'X' (A.java:10)
+
+Join point 'method-execution(void C.goo(java.lang.String))' in Type 'C' (A.java:6) advised by before advice from 'X' (A.java:11)
+
+Join point 'method-execution(void C.goo(java.lang.String))' in Type 'C' (A.java:6) advised by before advice from 'X' (A.java:10)
+....
+
+The first piece of advice matched both methods. The second only matched `goo()`.
+
+==== Annotation Value Matching
+
+This allows static matching of the values of an annotation - if the
+matching is done statically at weave time, it is possible to avoid some
+of the reflection that is currently required within the advice (in some
+cases). A typical use case is tracing where the trace level is defined
+by an annotation but may be switched OFF for a method if the annotation
+has a particular value. Perhaps tracing has been turned on at the type
+level and a few critical methods should not get traced. Here is some
+code showing the use case:
+
+[source, java]
+....
+enum TraceLevel { NONE, LEVEL1, LEVEL2, LEVEL3 }
+
+@interface Trace {
+  TraceLevel value() default TraceLevel.LEVEL1;
+}
+
+aspect X {
+  // Advise all methods marked @Trace except those with a tracelevel of none
+  before(): execution(@Trace !@Trace(TraceLevel.NONE) * *(..)) {
+    System.err.println("tracing "+thisJoinPoint);
+  }
+}
+
+public class ExampleOne {
+
+  public static void main(String[] args) {
+    ExampleOne eOne = new ExampleOne();
+    eOne.m001();
+    eOne.m002();
+    eOne.m003();
+    eOne.m004();
+    eOne.m005();
+    eOne.m006();
+    eOne.m007();
+  }
+
+  @Trace(TraceLevel.NONE)
+  public void m001() {}
+
+  @Trace(TraceLevel.LEVEL2)
+  public void m002() {} // gets advised
+
+  @Trace(TraceLevel.LEVEL3)
+  public void m003() {} // gets advised
+
+  @Trace(TraceLevel.NONE)
+  public void m004() {}
+
+  @Trace(TraceLevel.LEVEL2)
+  public void m005() {} // gets advised
+
+  @Trace(TraceLevel.NONE)
+  public void m006() {}
+
+  @Trace
+  public void m007() {} // gets advised
+
+}
+....
+
+Matching is currently allowed on all annotation value types *except*
+class and array. Also it is not currently supported for parameter
+annotation values.
+
+==== Changes since release candidate
+
+The only fix 1.6.0 final includes beyond the release candidate is a
+multi-threading problem in the weaver -
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=227029[bug 227029].
+
+==== Releases leading up to AspectJ 1.6.0
+
+AspectJ v1.6.0rc1- 16 Apr 2008
+
+AspectJ v1.6.0M2 - 26 Feb 2008
+
+AspectJ v1.6.0M1 - 16 Jan 2008
+
+'''''
diff --git a/docs/dist/doc/README-1.6.1.adoc b/docs/dist/doc/README-1.6.1.adoc
new file mode 100644
index 000000000..a59e3b0bb
--- /dev/null
+++ b/docs/dist/doc/README-1.6.1.adoc
@@ -0,0 +1,175 @@
+== AspectJ 1.6.1
+
+_© Copyright 2008 Contributors. All rights reserved._
+
+The main themes of AspectJ1.6.1 are better memory usage and faster
+weaving. This has been achieved through profiling of the weaving process
+and has resulted in some serious refactoring of the weaver component
+within AspectJ. It provides exactly the same functionality as in
+previous releases, it just weaves faster now, using less code and less
+memory. This readme will give an overview of the kind of changes made
+and what can be expected when using 1.6.1 compared to previous releases.
+
+The complete list of issues resolved for AspectJ 1.6.1 can be found with
+these bugzilla queries. The first lists bugs addressed (more than 60!)
+whilst the second details enhancements made in this release.
+
+* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.1&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&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&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=[Bugs
+resolved]
+* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.1&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&bug_severity=enhancement&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=[Enhancements
+implemented]
+
+'''''
+
+=== Refactored (https://bugs.eclipse.org/bugs/show_bug.cgi?id=231396[bug 231396])
+
+The bugzilla entry goes into more specifics on what has changed, the end
+result is that aspectjweaver.jar has had around 275 classes removed
+(about 25%) and has slimmed down by 350k (about 20%). In terms of
+performance for different scenarios:
+
+==== Straight compilation
+
+The refactoring effort has been focused on the weaver component, hence
+there is limited impact on the performance of source compilation but
+this comparison shows it is faster. Four scenarios are compared, in each
+scenario a different aspect is applied to the JDT compiler (just as a
+sample piece of source code).
+
+. 1100 source files, few aspects that target 859 join points.
+. 1100 source files, code style trace aspect targeting public methods
+(22000 join points)
+. 1100 source files, annotation style trace aspect (22000 join points)
+. 1100 source files, insane aspect (before(): within(*) \{}) (203000
+join points)
+
+image:perfSourceCompile_161.jpg[image]
+
+==== Binary weaving
+
+Moving on from source compilation to pure binary weaving, the
+improvements are more obvious. Here we are using the complete JVM
+classes jar 'rt.jar' as an example of a large jar file for weaving.
+
+. Binary weaving rt.jar (~12000 classes) with a simple aspect (1200 join
+points)
+. Binary weaving rt.jar (~12000 classes) with a code style trace aspect
+(121000 join points)
+. Binary weaving rt.jar (~12000 classes) with an annotation style trace
+aspect (121000 join points)
+. Binary weaving rt.jar (~12000 classes) with an insane aspect
+(before(): within(*) \{}) (352000 join points)
+
+image:perfBinaryWeave_161.jpg[image]
+
+==== Loadtime weaving
+
+The loadtime weaving improvements are similar to those seen for binary
+weaving (naturally). Here we are using the JDK tools jar 'tools.jar' as
+an example of a jar file for loadtime weaving.
+
+. Binary weaving tools.jar (~1900 classes) with a code style trace
+aspect
+. Binary weaving tools.jar (~1900 classes) with an insane aspect
+(before(): within(*) \{})
+
+image:perfLTW_161.jpg[image]
+
+The refactoring work has also reduced the amount of unnecessary garbage
+created on the heap during the weaving process. The next comparison
+shows roughly the reduction in amount of 'stuff' created on the heap
+during a weave. This isn't the max heap required to do a weave, it is
+just showing how many less temporary objects are allocated during an
+entire run of the weaver
+
+. First, the number of kilobytes of memory allocated from the heap
+during a weave of tools.jar with a code style trace aspect
+. Second, another run of the same thing
+. Third, this time using the insane aspect
+
+image:heapContents_161.jpg[image]
+
+So in terms of memory required, weaving the insane aspect into tools.jar
+created 1.4G of 'stuff' over the entire weaving process, compared to
+1.75G with 1.6.0.
+
+==== Loadtime weaving stress
+
+As well as addressing the memory usage of a single load time weaver, we
+have also looked at the use of load time weaving in a larger scale
+scenario, where multiple classloaders are being instantiated and
+discarded over time and each has an associated load time weaver. Under
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=210470[bug 210470] we
+looked in detail at whether the lifecycle of the weaver instance
+correctly matched the lifecycle of the associated classloader. It did
+not, but now it does! Here is a memory usage graph for AspectJ1.6.1 -
+this shows an application that spawns 7 threads which run continuously
+for a few minutes. Each thread repeatedly creates a classloader, weaves
+500 classes using it then discards the classloader. You can see that
+over time the memory is recovered correctly and when all threads
+complete (and all classloaders are orphaned), all the weavers are
+discarded.
+
+First, AspectJ 1.6.0, in which memory was never correctly recovered and
+so an OutOfMemory problem would always occur eventually.
+
+image:memLtwStress_160.jpg[image]
+
+And now AspectJ 1.6.1:
+
+image:memLtwStress_161.jpg[image]
+
+=== Incremental compilation
+
+Following on from the work done to improve compilation under Eclipse in
+AspectJ 1.6.0 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=221427[Bug
+221427] ) - we now support the building of 'broken code'
+(https://bugs.eclipse.org/bugs/show_bug.cgi?id=102733[bug 102733]). This
+is something the JDT has always been doing - where code containing
+errors continues to build (if recovery is possible) but should the
+actual methods containing the errors get invoked, an exception will be
+thrown at runtime. A number of users typically extract large projects
+from their library systems, knowing that they will only partially build
+in their current eclipse setup, but as long at they do not invoke the
+code containing the errors then they expect the rest of the project to
+run normally. AspectJ now allows this mode of operation, and it has the
+additional effect that the state of the project stays consistent, albeit
+with known errors, and this means AspectJ will more frequently do
+incremental builds rather than falling back to full builds because there
+was a compilation error.
+
+=== Language changes
+
+==== Optmized syntax for annotation value binding (https://bugs.eclipse.org/bugs/show_bug.cgi?id=234943[Bug234943])
+
+If only binding an annotation at a method-execution join point in order
+to access an *enum value* within it, there is a more optimal syntax that
+can be used to produce faster code. Given this setup:
+
+[source, java]
+....
+enum Colour { RED,GREEN,BLUE;}
+
+@interface ColouredAnnotation { Colour value(); }
+
+@ColouredAnnotation(Colour.RED)
+public void colouredMethod() { }
+....
+
+Current syntax:
+
+[source, java]
+....
+before(ColouredAnnotation anno): execution(* *(..)) && @annotation(anno) {
+  printTheColour(anno.value());
+}
+....
+
+New optional syntax:
+
+[source, java]
+....
+before(Colour col): execution(* *(..)) && @annotation(ColouredAnnotation(col)) {
+  printTheColour(col);
+}
+....
diff --git a/docs/dist/doc/README-1.6.10.adoc b/docs/dist/doc/README-1.6.10.adoc
new file mode 100644
index 000000000..5f571fce9
--- /dev/null
+++ b/docs/dist/doc/README-1.6.10.adoc
@@ -0,0 +1,50 @@
+== AspectJ 1.6.10
+
+_© Copyright 2010 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.6.10 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.6.10;target_milestone=1.6.10M1;target_milestone=1.6.10M2;target_milestone=1.6.10RC1[here]
+
+_Release info: 1.6.10 available 17-Nov-2010_
+
+=== Changes
+
+1.6.10 is primilarily just bug fixes for AspectJ, mainly in the areas of
+ITDs and generic aspects. However, there are a couple of important
+changes that users ought to be aware of:
+
+==== AJDT Memory usage
+
+Type demotion has been in use during loadtime weaving for a while now,
+this enables the load time weavers to discard state and recover it at a
+later time (and so generally run with a smaller memory footprint). Type
+demotion is now supported under AJDT in Eclipse and will enable AJDT to
+run with smaller heaps. This feature is still experimental and needs
+turning ON if you want to try it out. To turn it on, open your AspectJ
+project properties in eclipse and in the AspectJ Compiler section,
+scroll down to 'Other' and in the non-standard compiler options setting,
+specify:
+
+[source, text]
+....
+-Xset:minimalModel=true,typeDemotion=true
+....
+
+If I can get enough positive feedback about this option, it will be made
+the default. For a more detailed write up, check out the blog post:
+http://andrewclement.blogspot.com/2010/07/ajdt-memory-usage-reduction.html
+
+==== Runtime changes
+
+A big thank you to Abraham Nevado and his team who have been working on
+some issues to optimize loadtime weaving and the code generated by
+AspectJ. 1.6.10 includes some new changes to the aspectjrt.jar. The
+changes are new methods that enable the woven code to be a little
+shorter/neater. As we want to continue to have compatibility with older
+aspectjrt.jar a user needs to choose to activate these optimizations by
+specifying the option: -Xset:targetRuntime1_6_10=true. With that option
+on you will need to ensure you run against the aspectjrt.jar from a
+1.6.10 build.
+
+The changes are discussed in
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=323438[bug 323438]
diff --git a/docs/dist/doc/README-1.6.11.adoc b/docs/dist/doc/README-1.6.11.adoc
new file mode 100644
index 000000000..e5f4226a2
--- /dev/null
+++ b/docs/dist/doc/README-1.6.11.adoc
@@ -0,0 +1,106 @@
+== AspectJ 1.6.11
+
+_© Copyright 2010-2011 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.6.11 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.6.11;[here]
+
+_Release info: 1.6.11 available 15-Mar-2011_
+
+=== Notable Changes
+
+==== RC1 - Our own XML parser
+
+Due to the way AspectJ loads one of the standard XML parsers (for
+processing aop.xml) it was possible to get into a deadlock situation. To
+avoid this completely we now have our own XML parser inside for
+processing this files. It is basic but should support all the known
+syntax we have for aop files. To use it instead of the default (if you
+are encountering the deadlock) you need to specify this system property:
+org.aspectj.weaver.loadtime.configuration.lightxmlparser=true.
+
+'''''
+
+==== M2 - Multithreaded world access
+
+The weaver is backed by a representation of types called a world.
+Traditionally the worlds have supported single threads - and that is how
+they are used when doing compile time weaving or load time weaving.
+However in some configurations, e.g. pointcut matching under Spring, a
+single world instance may be getting accessed by multiple threads at the
+same time. Under
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=337855[bug337855] some
+changes have been made to better support this kind of configuration.
+
+==== M2 - various attribute deserialization issues
+
+In 1.6.9 we made some radical changes to the serialized form. It turns
+out some of the deserialization code wasn't handling these new forms
+quite right. This would manifest as an IllegalStateException or
+IndexOutOfBoundsException or similar, during attribute unpacking. These
+issues have now all been sorted out in 1.6.11.M2.
+
+==== M2 - further optimizations in model for AJDT
+
+More changes have been made for users trying out the
+-Xset:minimalModel=true option to try and reduce the memory used in
+their Eclipse/AJDT configurations. This option is discussed in detail
+http://andrewclement.blogspot.com/2010/07/ajdt-memory-usage-reduction.html[here].
+It now saves even more memory. Also, previously the amount of memory it
+recovered depended on compilation order (which the user has no control
+over), but now it is insensitive to ordering and should always recover
+the same amount across builds of the same project. With a bit more
+positive feedback on this option, it will become the default under AJDT.
+
+==== M2 - spaces in path names can cause problems
+
+AspectJ had problems if the paths it was being passed (e.g. aspectpath)
+included spaces. This is bug
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=282379[282379] and has now
+been fixed.
+
+'''''
+
+==== M1 - Annotation removal
+
+Traditionally AspectJ has taken an additive approach, where
+methods/fields/supertypes/annotations can only be added to types. Now,
+chaos would likely ensue if we allowed removal of supertypes, methods,
+etc, but we are seeing an increasing number of requirements to do more
+with annotations. What kinds of thing? Basically remove existing
+annotations, or modify existing annotations by changing their values.
+1.6.11 includes a new piece of syntax that we are thinking might be
+appropriate for one of these scenarios. 1.6.11 supports this:
+
+[source, java]
+....
+declare @field: int Foo.i: -@Anno;
+....
+
+Notice the '-' in front of the annotation, meaning 'removal'. The whole
+construct means 'remove the @Anno annotation from the int field called i
+in type Foo'. It is not yet supported on the other forms of declare @.
+
+==== M1 - Intertype innertypes
+
+More work has gone into this feature. It was originally added in 1.6.9
+but the inability to use it with binary weaving greatly reduced the
+usefulness. Fixes have gone into 1.6.11 to support binary weaving. What
+do we mean by intertype innertypes? Here is an example:
+
+[source, java]
+....
+class Foo {
+  public void m() {
+    System.out.println(Inner.i);
+  }
+}
+
+aspect X {
+  public static class Foo.Inner {
+    static int i = 34;
+  }
+}
+....
+
+Only static inner types are supported.
diff --git a/docs/dist/doc/README-1.6.12.adoc b/docs/dist/doc/README-1.6.12.adoc
new file mode 100644
index 000000000..ed9951d4d
--- /dev/null
+++ b/docs/dist/doc/README-1.6.12.adoc
@@ -0,0 +1,244 @@
+== AspectJ 1.6.12
+
+_© Copyright 2010-2011 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.6.12 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.6.12;[here]
+
+_Release info:_
+
+  * _1.6.12 available 18-Oct-2011_
+  * _1.6.12.RC1 available 3-Oct-2011_
+  * _1.6.12.M2 available 18-Aug-2011_
+  * _1.6.12.M1 available 7-Jun-2011_
+
+=== Notable Changes
+
+==== RC1 - annotation value matching and !=
+
+Prior to this change it was only possible to specify an annotation match
+like this: +
+ +
+get(@Anno(someValue=1) * *) || get(@Anno(someValue=3) * *) +
+
+Now it is possible to use != and write this: +
+ +
+get(@Anno(someValue!=2) * *) +
+
+This can enable a group of annotated elements to be more easily
+identified. +
+ +
+
+==== RC1 - More flexible pointcut/code wiring in aop.xml
+
+Prior to this version the wiring was quite limited. In order to wire a
+pointcut to a piece of code the user needed to write an abstract aspect
+that included an abstract pointcut and some advice attached to that
+abstract pointcut. Then compile this aspect and finally write the XML to
+concretize the abstract pointcut. With 1.6.12 more flexibility has been
+added and for some cases there can be no need for that abstract aspect.
+
+This is a work in progress but now you can write this in the aop.xml:
+
+[source, xml]
+....
+<concrete-aspect name="MyAspect">
+  <before pointcut="execution(* Hello.say2(..)) AND args(message)"
+   invokeClass="SomeRegularJavaClass"
+   invokeMethod="someMethod(JoinPoint tjp, java.lang.String message)"/>
+  <after pointcut="execution(* Hello.say2(..)) AND args(message)"
+   invokeClass="SomeRegularJavaClass"
+   invokeMethod="someOtherMethod(JoinPoint tjp, java.lang.String message)"/>
+</concrete-aspect>
+
+public class SomeRegularJavaClass {
+
+  public static void someMethod(org.aspectj.lang.JoinPoint tjp, String s) {
+    System.out.println("in advice4: s="+s+" at "+tjp);
+  }
+
+  public static void someOtherMethod(org.aspectj.lang.JoinPoint tjp, String s) {
+    System.out.println("in advice5: s="+s+" at "+tjp);
+  }
+}
+....
+
+In this example there is a simple regular java class containing some
+static methods. In the XML these can be joined to pointcuts, kind as if
+they were advice. Notice in the XML it specifies:
+
+* The pointcut
+* The invokeClass - the fully qualified name of the class containing the
+Java method
+* The invokeMethod - the method, including signature in the specified
+class.
+
+Due to the method specification being in XML the parameter types must be
+fully specified. The only exception to this rule is that the AspectJ
+core types JoinPoint (and JoinPoint.StaticPart) do not have to be fully
+qualified (see the example above). *Important:* notice that in the case
+above which does argument binding, the names are bound according to the
+XML specification, not according to the parameter names in the Java
+code.
+
+Around advice is also supported (the return type of the method must
+match the joinpoint return type). The example shows after advice,
+currently there is no way to specify either after returning or after
+finally, there is only after.
+
+Expanding this further would enable support for all the code style
+features in the XML. Some of the language features like declare
+annotation cannot be done in annotation style aspects but the XML
+doesn't have the same kind of restrictions. If anyone wants to help out
+by fleshing this area of the weaver out, let me know and I'll help you
+get started!
+
+'''''
+
+==== M2 - thisAspectInstance (https://bugs.eclipse.org/bugs/show_bug.cgi?id=239649[bug239649])
+
+There is now a new well known name that you can use in the if clauses in
+your aspects. thisAspectInstance provides access to the aspect instance.
+Here is an example:
+
+[source, java]
+....
+aspect X {
+  boolean doit() {
+    System.out.println("In instance check method doit()");
+    return true;
+  }
+
+  before():execution(* m(..)) && if(thisAspectInstance.doit()){
+    System.out.println(thisJoinPoint);
+  }
+}
+....
+
+Now why not just use `X.aspectOf()` instead of `thisAspectInstance`? Well,
+`thisAspectInstance` is quite useful when working with abstract/concrete
+aspects:
+
+[source, java]
+....
+abstract aspect X {
+abstract pointcut p();
+
+boolean doit() {
+    return true;
+  }
+
+  before():p()  && if(thisAspectInstance.doit()){
+    System.out.println(thisJoinPoint);
+  }
+}
+
+aspect Y extends X {
+
+  pointcut p(): execution(* m(..));
+
+}
+....
+
+Now thisAspectInstance will be an instance of the Y, not X. It enables
+the aspect instance to be used in some kind of check/guard that will
+avoid the costly creation of a thisJoinPoint object if the advice isn't
+going to run. *Note:* right now this only works for singleton aspects.
+If you have need of it with other instantiation models, please comment
+on https://bugs.eclipse.org/bugs/show_bug.cgi?id=239649
+
+==== M2 - weaving groovy
+
+Although we have been successfully weaving groovy for a long time, it is
+becoming more popular and a few issues have been uncovered when using
+non-singleton aspects with groovy code. These have been fixed.
+
+==== M2 - AJDT memory
+
+The release notes for the last few versions of AspectJ have mentioned
+two options (minimalModel and typeDemotion) which can be switched on to
+reduce memory consumption. They have had enough field testing now and
+from 1.6.12.M2 onwards they are on by default. Users should see a
+reduction in memory consumed by AspectJ projects in AJDT. It won't
+affect load time weaving. It may also help command line (or Ant) compile
+time weaving. If these options cause a problem then please raise a
+bugzilla but in the interim you could work around the problem by
+actively turning them off by specifying
+-Xset:minimalModel=false,typeDemotion=false in the project properties
+for your AspectJ project.
+
+==== M2 - Java7 weaving support
+
+Some preliminary work has been done to support Java7. Java7 class files
+must contain the necessary extra verifier support attributes in order to
+load successfully on a Java7 VM - the attributes were only optional in
+Java6. It is possible to force loading of classes missing the attributes
+but that requires use of a -XX option. AspectJ 1.6.12.M2 should create
+these for you if you weave Java7 level class files. Nothing has been
+done yet to rebase AspectJ on a version of the Eclipse compiler that
+supports Java7 language constructs - that will happen after Eclipse
+3.7.1 is out.
+
+'''''
+
+==== M1 - synthetic is supported in pointcut modifiers https://bugs.eclipse.org/bugs/show_bug.cgi?id=327867[327867]
+
+It is now possible to specify synthetic in pointcuts:
+
+[source, java]
+....
+pointcut p(): execution(!synthetic * *(..));
+....
+
+==== M1 - respect protection domain when generating types during weaving https://bugs.eclipse.org/bugs/show_bug.cgi?id=328099[328099]
+
+This enables us to weave signed jars correctly. AspectJ sometimes
+generates closure classes during weaving and these must be defined with
+the same protection domain as the jar that gave rise to them. In
+1.6.12.M1 this should now work correctly.
+
+==== M1 - Suppressions inline with the JDT compiler https://bugs.eclipse.org/bugs/show_bug.cgi?id=335810[335810]
+
+Starting with Eclipse 3.6, the Eclipse compiler no longer suppresses raw
+type warnings with @SuppressWarnings("unchecked"). You need to use
+@SuppressWarnings("rawtypes") for that. AspectJ has now been updated
+with this rule too.
+
+==== M1 - Optimized annotation value binding for ints https://bugs.eclipse.org/bugs/show_bug.cgi?id=347684[347684]
+
+The optimized annotation value binding now supports ints - this is for
+use when you want to match upon the existence of an annotation but you
+don't need the annotation, you just need a value from it. This code
+snippet shows an example:
+
+[source, java]
+....
+@interface SomeAnnotation {
+  int i();
+}
+
+before(int i): execution(* *(..)) && @annotation(SomeAnnotation(i)) {
+....
+
+Binding values in this way will result in code that runs *much* faster
+than using pointcuts that bind the annotation itself then pull out the
+value.
+
+Under that same bug some changes were made to match values by name when
+binding too. Suppose the annotation had multiple int values, how would
+we select which int to bind? AspectJ will now use the name (if it can)
+to select the right value:
+
+[source, java]
+....
+@interface SomeAnnotation {
+  int mods();
+  int flags();
+}
+
+before(int flags): execution(* *(..)) && @annotation(SomeAnnotation(flags)) {
+....
+
+Here the use of 'flags' as the name of the value being bound will ensure
+the 'flags' value from any SomeAnnotation is bound and not the 'mods'
+value.
diff --git a/docs/dist/doc/README-1.6.2.adoc b/docs/dist/doc/README-1.6.2.adoc
new file mode 100644
index 000000000..a6b88ffee
--- /dev/null
+++ b/docs/dist/doc/README-1.6.2.adoc
@@ -0,0 +1,84 @@
+== AspectJ 1.6.2
+
+_© Copyright 2008 Contributors. All rights reserved._
+
+The main theme of AspectJ1.6.2 was improved IDE incremental performance
+and a number of changes have gone in to improve how AspectJ and AJDT
+communicate - greatly reducing the time taken to perform an incremental
+compile (more details below). 1.6.2 also includes a number of fixes and
+enhancements covering areas such as:
+
+* better support for generics and intertype declarations
+* better support for annotation style syntax
+* improvements to ajdoc
+* bringing the AspectJ structure model more in line with the JDT model
+
+Many thanks to all the users that helped diagnose problems, provide
+testcases and contribute fixes. In particular:
+
+* Dave Whittaker - for generics and intertype declaration testing and
+testcases
+* Jason Naylor, Arturo Salazar - for ajdoc testcases, fixes and design
+input
+* Andrew Eisenberg - for helping shape the AJDT/AspectJ interface and
+improving incremental
+
+The complete list of issues resolved for AspectJ 1.6.2 (more than 60)
+can be found with this bugzilla query:
+
+* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.2&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=[Bugs
+resolved]
+
+'''''
+
+=== Incremental compilation (https://bugs.eclipse.org/bugs/show_bug.cgi?id=247742[bug 247742], https://bugs.eclipse.org/bugs/show_bug.cgi?id=245566[bug 245566], https://bugs.eclipse.org/bugs/show_bug.cgi?id=243376[bug 243376])
+
+Two main changes in this area.
+
+* Better communication between AJDT and AspectJ. The interface between
+the two has been modified so that AJDT can give more input to AspectJ
+about what needs to be done for an incremental compile, rather than
+having AspectJ discover it each time.
+* Structure model changes. The AspectJ structure model (of types in a
+project and the weaving amongst them) allows handles to be created for
+every node, as a lightweight reference to the elements of the model.
+These handles were similar to those that JDT uses for references to
+elements of a project but not identical. Many many fixes have gone in to
+bring the handle formats closer and closer. For example including src
+folders as elements in the AspectJ model and using the fully correct set
+of JDT delimiters throughout each handle. This means there is no longer
+an expensive transformation cost in going from an AspectJ element to its
+related JDT element and no need for AJDT to maintain a more JDT like
+version of the AspectJ structure model. The imminent development builds
+of AJDT will utilise these changes.
+
+_What difference does it make?_
+
+For every kind of build there are two numbers to take into account.
+Firstly there is the time spent in the compiler (time spent compiling
+and weaving), secondly there is the time spent in AJDT (time spent
+communicating what happened back to the user via the problems view,
+gutter annotations). Values for these times can be seen by opening the
+'AJDT Event Trace View' in eclipse. The changes within AspectJ obviously
+effect the time spent in the compiler and that is described as 'time
+spent in AJDE' within the event trace view (AJDE being the compiler
+wrapper invoked by AJDT).
+
+For a 1000 source file AspectJ project, the times spent in AJDE have
+changed as follows for a single whitespace change and save operation:
+
+* For a sourcefile unaffected by aspects. Was 1828ms, now 75ms.
+* For a sourcefile affected by some advice. Was 1844ms, now 90ms.
+* For a sourcefile affected by lots of advice. Was 1937ms, now 188ms.
+
+The AspectJ changes are done to support this, but we are still bedding
+them down in AJDT. If you want to see numbers like those above you need
+to install the latest AJDT dev builds for Eclipse 3.4 (an AJDT 1.6.1 dev
+build from the dev update site:
+https://download.eclipse.org/tools/ajdt/34/dev/update ) and then after
+starting Eclipse, select 'Window>Preferences' and in the AspectJ tab
+select 'Incremental Compiler Optimizations'. Let us know how you get on!
+When it has had enough testing it will be made the default and then is
+likely to be back ported to Eclipse 3.3 AJDT.
+
+'''''
diff --git a/docs/dist/doc/README-1.6.3.adoc b/docs/dist/doc/README-1.6.3.adoc
new file mode 100644
index 000000000..1609eb35f
--- /dev/null
+++ b/docs/dist/doc/README-1.6.3.adoc
@@ -0,0 +1,86 @@
+== AspectJ 1.6.3
+
+_© Copyright 2008 Contributors. All rights reserved._
+
+* xref:#split[Split matching/weaving]
+* xref:#bugsfixed[Bugs fixed]
+* xref:#notable[Notable bug fixes]
+* xref:#whatsnext[What's next?]
+
+'''''
+
+[[split]]
+=== Split matching/weaving
+
+The main goal of AspectJ 1.6.3 was to make the line between matching and
+weaving more explicit and introduce the notion of a matcher artifact.
+This matcher would enable reuse of the semantics of AspectJ pointcut
+matching without including the unnecessary code that is the weaver. Why?
+In some environments, for example Spring AOP, the weaving may be done in
+an entirely different way and the default weaver included in
+aspectjweaver.jar is just unnecessary code. Some users also find they
+have trouble getting approval for using the 'aspectjweaver.jar' in their
+projects because it includes a bytecode modification library, even when
+they are not using that code.
+
+The result of this work is documented in
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=246125[bug 246125] and
+there is now a new jar file in the distribution called
+org.aspectj.matcher.jar that includes a first pass at the matching code.
+It is not quite as slimmed down as it could be but is a first pass that
+includes no bytecode modification toolkit.
+
+To use this matcher standalone it simply requires an abstraction of some
+type system to be plugged in. The matcher code can then be used to parse
+standard pointcuts and answer questions about whether they match against
+that type system. There is no documentation on how to do this yet, as we
+don't think many users will be contributing new type systems, but
+internally we are working on an Eclipse JDT type system abstraction that
+will enable us to show matches in AJDT without actually compiling code
+(currently the two type system abstractions we ship are bytecode based
+and reflection based - both of which require compilation).
+
+'''''
+
+[[bugsfixed]]
+=== Bugs fixed
+
+The complete list of issues resolved for AspectJ 1.6.3 (more than 50)
+can be found with this bugzilla query:
+
+* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.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=[Bugs
+resolved]
+
+During 2008, there have been four AspectJ releases, fixing almost 200
+issues.
+
+'''''
+
+[[notable]]
+=== Notable bug fixes
+
+* More improvements to the way AspectJ/AJDT communicate (251277, 249216,
+258325)
+* More ajdoc improvements (256514)
+* Better support for non standard annotation style parameter ordering
+(164573, 219419)
+* Fixed long standing issue with extending Spring SecurityInterceptor
+(252722)
+* Ensure parameter annotations made on an ITD reach the target affected
+type (256669)
+
+'''''
+
+[[whatsnext]]
+=== What's next?
+
+The JDT World should be completed in the 1.6.4 timeframe and that will
+surface as benefits in AJDT, possibly leading to better LTW tooling.
+Some improved syntax for intertype declarations is a possible candidate
+feature (see discussion in
+https://dev.eclipse.org/mhonarc/lists/aspectj-users/msg10208.html[this
+mailing list thread]). A possible introduction of a code style syntax
+for the mixin style that is @DeclareParents (and a renaming of
+@DeclareParents to perhaps DeclareMixin or DeclareDelegate).
+
+'''''
diff --git a/docs/dist/doc/README-1.6.4.adoc b/docs/dist/doc/README-1.6.4.adoc
new file mode 100644
index 000000000..dc3a71816
--- /dev/null
+++ b/docs/dist/doc/README-1.6.4.adoc
@@ -0,0 +1,245 @@
+== AspectJ 1.6.4
+
+_© Copyright 2009 Contributors. All rights reserved._
+
+* xref:#compilation[Compilation times]
+* xref:#language[Language enhancements]
+* xref:#bugsfixed[Bugs fixed]
+* xref:#whatsnext[What's next?]
+
+'''''
+
+[[compilation]]
+=== Compilation times
+
+In AspectJ 1.6.4 the goal was to improve the IDE experience, through a
+combination of improved compilation speed (both full builds and
+incremental builds), improved support for multiple-project
+configurations, and improved feedback in the editor. The following
+sections go into details on each of those topics.
+
+*Full Compilation*
+
+As an example project, all the measurements here are based on the
+modified JDT compiler that AspectJ uses internally. It is 1100 source
+files and includes aspects that affect around 850 join points. Here are
+the full build times in AJDT:
+
+AJDT 1.6.3 (uses AspectJ 1.6.3)
+
+[source, text]
+....
+21352ms
+21597ms
+21502ms
+....
+
+AJDT 1.6.5dev builds (use AspectJ 1.6.4)
+
+[source, text]
+....
+19811ms
+19802ms
+19504ms
+....
+
+About 1.5-2 seconds faster for this example.
+
+*Incremental Compilation and multi-project scenarios*
+
+In most common project configurations there are multiple eclipse
+projects in some kind of dependency hierarchy. Depending on what changes
+in a top level project, those downstream may need to be rebuilt. The
+analysis around this area has greatly improved in AspectJ 1.6.4, and
+this has resulted in much reduced incremental build times. The example
+timed here is around 20 AspectJ projects in a hierarchy, and a change is
+made to a source file in the top level project and build times are
+observed for the downstream projects.
+
+The timings reported here are accessible to anyone with AJDT installed -
+just open the 'AJDT Event Trace View' and it will report ongoing
+information about what the compiler/weaver and AJDT are up to. Be aware
+that data is only recorded in this view if it is open - so for optimal
+performance it should be shutdown, but it is useful for debugging
+scenarios or collecting basic benchmark numbers. Within the event trace
+view output, the time recorded for 'time spent in AJDE' represents the
+time spent in the compiler: analysing what has changed on the classpath,
+building code, weaving code.
+
+Initially this is using AJDT 1.6.2 (which embeds AspectJ 1.6.3):
+
+[source, text]
+....
+Type of change: adding a new method to a type
+Project build times (first one is the compile of our change, the rest are for downstream projects):
+462ms, 4ms, 145ms, 8ms, 9ms, 287ms, 471ms, 222ms, 1028ms, 143ms, 505ms, 199ms, 261ms, 1224ms,
+321ms, 704ms, 75ms, 233ms, 257ms
+Summary: Total time spent in the compiler for that change: 6558ms
+---
+Type of change: whitespace change (adding just a harmless space character)
+Project build times (first one is the compile of our change, the rest are for downstream projects):
+229ms, 5ms, 10ms, 9ms, 10ms, 79ms, 43ms, 62ms, 80ms, 37ms, 64ms, 32ms, 79ms,
+154ms, 94ms, 189ms, 72ms, 144ms, 205ms
+Summary: Total time spent in the compiler for that change: 1597ms
+....
+
+Now with AspectJ 1.6.5 dev builds (which embed AspectJ 1.6.4):
+
+[source, text]
+....
+Type of change: adding a new method to a type
+Project build times (first one is the compile of our change, the rest are for downstream projects):
+288ms, 3ms, 143ms, 2ms, 2ms, 162ms, 244ms, 89ms, 489ms, 113ms, 277ms, 108ms, 143ms, 626ms,
+135ms, 260ms, 2ms, 96ms, 6ms
+Summary: Total time spent in the compiler for that change: 3188ms down from 6558ms
+
+Type of change: whitespace change (adding just a harmless space character)
+Project build times (first one is the compile of our change, the rest are for downstream projects):
+101ms, 1ms, 1ms, 1ms, 0ms, 1ms, 1ms, 1ms, 1ms, 1ms, 0ms, 1ms, 1ms, 2ms, 0ms, 1ms, 0ms, 2ms, 2ms
+Summary: Total time spent in the compiler for that change: 118ms (down from 1597ms)
+....
+
+Improvements all round, and almost instant builds now for whitespace
+changes, even in large project setups.
+
+In addition the compilation times are also improved in situations where
+AspectJ projects depend upon Java projects and where aspectpath is used.
+AJDT 1.6.5 dev builds also include some changes that really speed up
+builds.
+
+=== Better editor feedback
+
+Under https://bugs.eclipse.org/bugs/show_bug.cgi?id=246393[bug 246393]
+the problem has been addressed where sometimes spurious errors would
+appear throughout the editor for a file in AJDT when just one single
+simple syntax errors exists. More detail on this problem can be found
+http://andrewclement.blogspot.com/2009/02/aspectj-fixing-reverse-cascade-errors.html[here].
+
+'''''
+
+[[language]]
+=== Language Enhancements
+
+*Optimizing support for maintaining per join point state*
+
+The traditional way to maintain state on a per join point basis involves
+using the JoinPoint.StaticPart as a key into a map:
+
+[source, java]
+....
+aspect X pertypewithin(*) {
+  Map<JoinPoint.StaticPart,Timer> timerMap = ...
+
+  Object around(): execution(public * *(..)) {
+    Timer timerToUse = timerMap.get(thisJoinPointStaticPart);
+    timerToUse.start();
+    Object o =  proceed();
+    timerToUse.stop();
+    return o;
+  }
+}
+....
+
+These map lookups are slow. In AspectJ 1.6.4 there is a new getId()
+method on the JoinPoint.StaticPart object. The ids for all affected join
+points within a target type are unique (and start from 0) - they are
+ideal for array lookups. So using this the above aspect can be
+rewritten:
+
+[source, java]
+....
+aspect X pertypewithin(*) {
+  Timer[] timerArray = ...
+
+  Object around(): execution(public * *(..)) {
+    Timer timerToUse = timerArray[thisJoinPointStaticPart.getId()];
+    timerToUse.start();
+    Object o =  proceed();
+    timerToUse.stop();
+    return o;
+  }
+}
+....
+
+much faster. Just be aware that the ids are only unique within an
+affected target type - hence the use of pertypewithin in this example to
+ensure there is an aspect instance (and so a different array) for each
+advised type.
+
+See related https://bugs.eclipse.org/bugs/show_bug.cgi?id=89009[bug
+89009] for the full discussion
+
+=== @DeclareMixin
+
+The annotation style declare parents support (@DeclareParents) has been
+(rightly) criticized because it really does not offer an equivalent to
+what is possible with code style declare parents, it really offers a
+mixin strategy. It also has limitations such as the delegate instance
+used to satisfy any method invocations on an affected target cannot
+access the object instance for which it is acting as a delegate. To
+address these concerns a proper mixin notation has been introduced that
+makes it more clear that a mixin strategy is being employed and it
+addresses the problem of the mixin delegate accessing the affected
+target instance.
+
+The @DeclareMixin annotation is attached to a factory method which
+returns instances of the delegate. Here is a basic example:
+
+[source, java]
+....
+// The factory method that can build the delegate instance is annotated with @DeclareMixin.
+// The annotation value defines the type pattern for targets of the mixin.
+// The parameter is the object for which a delegate is being constructed.
+// The interface that will be mixed in is the return value of the factory method.
+@DeclareMixin("org.xyz..*")
+public static SomeInterface createDelegate(Object instance) {
+  return new SomeImplementation(instance);
+}
+....
+
+More examples are
+https://www.eclipse.org/aspectj/doc/released/adk15notebook/ataspectj-itds.html[here
+in the online documentation].
+
+Going forward attempts will be made to try and make @DeclareParents
+behave more like code style - if this cannot be done it is likely to be
+deprecated.
+
+'''''
+
+[[bugsfixed]]
+=== Bugs fixed
+
+The complete list of issues resolved for AspectJ 1.6.4 (more than 70)
+can be found with this bugzilla query:
+
+* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.4&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=[Bugs
+resolved]
+
+'''''
+
+[[whatsnext]]
+=== What's next?
+
+*More incremental build enhancements*
+
+A number of situations still exist where incremental compile speeds
+still needs optimizing, particular when capabilities like aspectpath or
+inpath are used.
+
+*Build state persistence*
+
+Between restarts of Eclipse the state of each project is not recorded -
+hence full builds are required upon restart. The state (and associated
+relationship model) should be persisted between restarts, but both of
+these need a review first to ensure they are not larger than they need
+to be.
+
+*Memory consumption*
+
+Both for source compilation and load-time weaving scenarios. The size of
+the model in the IDE needs reviewing, and also the type map within the
+weaver. Although the type map uses Weak/Soft references to try and
+better control how it uses memory, the JVM policies for managing these
+references vary wildly and so some work needs to be done to allow for
+these differences.
diff --git a/docs/dist/doc/README-1.6.5.adoc b/docs/dist/doc/README-1.6.5.adoc
new file mode 100644
index 000000000..28396df40
--- /dev/null
+++ b/docs/dist/doc/README-1.6.5.adoc
@@ -0,0 +1,14 @@
+== AspectJ 1.6.5
+
+_© Copyright 2009 Contributors. All rights reserved._
+
+[[bugsfixed]]
+=== Bugs fixed
+
+The complete list of issues resolved for AspectJ 1.6.5 can be found with
+this bugzilla query:
+
+* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.5&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=[Bugs
+resolved]
+
+'''''
diff --git a/docs/dist/doc/README-1.6.6.adoc b/docs/dist/doc/README-1.6.6.adoc
new file mode 100644
index 000000000..940b2cf96
--- /dev/null
+++ b/docs/dist/doc/README-1.6.6.adoc
@@ -0,0 +1,64 @@
+== AspectJ 1.6.6
+
+_© Copyright 2009 Contributors. All rights reserved._
+
+[[bugsfixed]]
+=== Bugs fixed
+
+The complete list of issues resolved for AspectJ 1.6.6 can be found with
+this bugzilla query:
+
+* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.6&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=[Bugs
+resolved]
+
+'''''
+
+=== Changes
+
+*Java5*
+
+The features of Java5 (generics, autoboxing, covariance, etc) are being
+exploited in the AspectJ codebase. This does not in any way change the
+generated code or supported source code, or the dependencies that code
+has, but it *does* mean that AspectJ requires Java5 in order to run. The
+ability to use typed collections has already flushed out a few issues
+within the codebase, improving the quality of AspectJ.
+
+ +
+
+*Closing streams*
+
+Some routes through AspectJ were leaving inputstreams open and this has
+now been fixed. For example if supplying a user written configuration
+file for Lint options. Thanks to Michael Pradel for supplying patches to
+fix these issues.
+
+ +
+
+*Concurrency (281654)*
+
+Fix to address a problem seen when using the weaver in a highly
+concurrent environment. Thanks to Kristian Rosenvold for the patch.
+
+ +
+
+*Incremental compilation*
+
+A few fixes to problems seen only on incremental builds, problem areas
+included:
+
+* problems when fully qualifying the target type in an intertype
+declaration (269652)
+* problems when using annotation style pointcuts and reference pointcuts
+together (286341)
+
+ +
+
+*JavadocRunner in NetBeans*
+
+Fixed by a patch from Joseph A. Levin - thanks!
+
+ +
+
+*Various fixes/enhancements to the structure model to fix issues with
+feedback on weaving in AJDT*
diff --git a/docs/dist/doc/README-1.6.7.adoc b/docs/dist/doc/README-1.6.7.adoc
new file mode 100644
index 000000000..9104f2d18
--- /dev/null
+++ b/docs/dist/doc/README-1.6.7.adoc
@@ -0,0 +1,180 @@
+== AspectJ 1.6.7
+
+_© Copyright 2009 Contributors. All rights reserved._
+
+AspectJ 1.6.7 includes some radical internal changes. These improvements
+enable faster compilation, faster binary weaving, faster load time
+weaving and in some situations faster generated code.
+
+=== Pointcut timers
+
+Until 1.6.7 there has not really been a way to determine if it is just
+one of your pointcuts that is hurting your weaving performance. In 1.6.7
+it is possible to turn on timers for pointcuts. These timers show the
+time spent in the weaver matching the pointcut components against join
+points. The details on this feature are here:
+http://andrewclement.blogspot.com/2009/11/aspectj-profiling-pointcut-matching.html[Profiling
+pointcut matching]. Basically by turning on the options '-timers
+-verbose' on the command line (or via Ant), output will be produced that
+looks a little like this:
+
+[source, text]
+....
+Pointcut matching cost (total=6532ms for 675000 joinpoint match calls):
+Time:482ms (jps:#168585) matching against
+    (staticinitialization(*y*.()) && persingleton(SimpleAspect))
+Time:3970ms (jps:#168585) matching against
+    (execution(* *t*.*(*)) && persingleton(SimpleAspect))
+Time:538ms (jps:#168584) matching against
+    (execution(* *f*(..)) && persingleton(SimpleAspect))
+Time:1536ms (jps:#168584) matching against
+    (execution(* java.lang.CharSequence+.*e*(..)) && persingleton(SimpleAspect))
+Time:4ms (jps:#662) matching against
+    (within(*p*) && persingleton(SimpleAspect))
+....
+
+It shows the component, the number of joinpoints (jps) the weaver
+attempted to match it against and how many milliseconds were spent
+performing those matches. The options can also be turned on
+http://contraptionsforprogramming.blogspot.com/2009/11/getting-aspectj-pointcut-matching-timer.html[]through
+AJDT. Armed with this information you can optimize your pointcuts or
+post on the mailing list asking for help. The timers can even be turned
+on for load time weaving.
+
+=== Faster matching
+
+The changes to enable pointcut profiling enabled some targeted work to
+be done on the matching algorithms. These have remained unchanged for a
+few years, but in 1.6.7 have received a bit of an overhaul. 'Fast match'
+has been implemented for the execution() pointcut, drastically reducing
+weave times for heavy users of execution - more details
+http://andrewclement.blogspot.com/2009/11/aspectj-how-much-faster-is-aspectj-167.html[here].
+The pointcut cost calculator (which is used to sort pointcuts to
+optimize matching speed) has been reviewed and after determining that
+this() ought to be considered cheaper than call() - any user combining
+those two pointcut designators should see an improvement (one users
+build time reduced from 38minutes to 6minutes with that change!).
+
+As well as faster matching there is also less exploration to determine a
+match. Visitors that walk hierarchies and discover methods now terminate
+as early as possible once they can determine something is a match or is
+definetly not a match. This reduces memory usage, speeds up weaving and
+reduces the occurrences of those annoying 'cantFindType' messages.
+
+=== aop.xml processing
+
+The processing of include/exclude entries in aop.xml has been rewritten.
+It now optimizes for many more common patterns. If a pattern is
+optimized then there is no need to ask the weaver to do an expensive
+include/exclude match. More details
+http://andrewclement.blogspot.com/2009/12/aspectj-167-and-faster-load-time.html[here].
+
+=== Less need to tweak options for load time weaving
+
+A number of options were previously configurable for load time weaving
+that were considered experimental. These options have now been tested
+enough in the field that they are considered fully reliable and are on
+by default in 1.6.7. If you have been using either of these:
+
+* typeDemotion
+* runMinimalMemory
+
+then please delete them from your weaver options section, the weaver
+will now do the right thing out of the box.
+
+=== Benchmarking memory and performance
+
+All those changes above, and some additional tweaks, mean we are now
+using less memory than ever before and getting things done more quickly.
+
+http://andrewclement.blogspot.com/2009/12/aspectj-167-and-faster-load-time.html[This
+post] discusses the details. From that article, the graph below shows
+the speed and memory consumption of the various AspectJ 1.6 releases
+when load time weaving a small application loading in Tomcat. For each
+of 10 iterations (x axis), the top comparison is startup time in
+milliseconds, the lower comparison is memory used in bytes.
+
+image:167Memory.png[image]
+
+=== Annotation binding
+
+All those changes affect compilation/weaving but what about the code
+that actually runs? One user, Oliver Hoff, raised a query on the
+performance of annotation binding. His case uncovered an old TODO left
+in the code a few years ago:
+
+[source, text]
+....
+// OPTIMIZE cache result of getDeclaredMethod and getAnnotation?
+....
+
+Annotation binding has become a very common use case since that was
+written and 1.6.7 was the time TODO it.
+
+The result is an optimization for the general case of binding an
+annotation, but also support for a new bit of syntax that aids binding
+of a string annotation member value - using this latter syntax generates
+extremely fast code.
+
+Here are some numbers for a simple benchmark retrieving the annotation
+value at an execution join point in different ways. The three scenarios
+look like this (where the annotation type is 'Marker' and it has a
+String value field called 'message'):
+
+[source, java]
+....
+// CaseOne: annotation value fetching is done in the advice:
+pointcut adviceRetrievesAnnotation(): execution(@Marker * runOne(..));
+before(): adviceRetrievesAnnotation() {
+  Marker marker = (Marker) ((MethodSignature)
+      thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Marker.class);
+  String s = marker.message();
+}
+
+// CaseTwo: annotation binding is done in the pointcut, advice retrieves message
+pointcut pointcutBindsAnnotation(Marker l): execution(@Marker * runTwo(..)) && @annotation(l);
+before(Marker l): pointcutBindsAnnotation(l) {
+  String s = l.message();
+}
+
+// CaseThree: annotation binding directly targets the message value in the annotation
+pointcut pointcutBindsAnnotationValue(String msg):
+  execution(@Marker * runThree(..)) && @annotation(Marker(msg));
+before(String s): pointcutBindsAnnotationValue(s) {
+  // already got the string
+}
+....
+
+Before 1.6.7, case 2 was slower than case 1 and case 3 wasn't supported
+syntax. The two bugs with more info are
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=296484[Bug 296484] and
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=296501[Bug 296501].
+
+Now this is a micro benchmark, slightly unrepresentative of the real
+world because the advice isn't doing anything else, but it does really
+stress the AspectJ binding code. For the benchmark numbers the join
+points advised by those advice were invoked 1,000,000 times. AspectJ
+1.6.7:
+
+[source, text]
+....
+Manually fetching annotation with getAnnotation(): 645ms
+Binding annotation with @annotation(Marker): 445ms  (was >20 *seconds* for 1.6.6, due to an extra reflection call)
+Binding annotation value with @annotation(Marker(message)): 3ms
+....
+
+The new syntax is definetly the best way to bind an annotation string
+value.
+
+'''''
+
+[[bugsfixed]]
+==== Bugs fixed
+
+The complete list of issues resolved for AspectJ 1.6.7 can be found with
+this bugzilla query:
+
+* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.7&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=[Bugs
+resolved]
+
+'''''
diff --git a/docs/dist/doc/README-1.6.8.adoc b/docs/dist/doc/README-1.6.8.adoc
new file mode 100644
index 000000000..0adbd557a
--- /dev/null
+++ b/docs/dist/doc/README-1.6.8.adoc
@@ -0,0 +1,87 @@
+== AspectJ 1.6.8
+
+_© Copyright 2009 Contributors. All rights reserved._
+
+The first sentence in the 1.6.7 readme was 'AspectJ 1.6.7 includes some
+radical internal changes.'
+
+Unfortunately not enough testing was done on 1.6.7 and two nasty issues
+were found that really needed addressing. Fixes for these issues are all
+that is new in 1.6.8.
+
+=== Incorrect treatment of some aop.xml include/exclude patterns
+
+See https://bugs.eclipse.org/bugs/show_bug.cgi?id=298786[Bug 298786]
+
+Basically, if a certain combination of includes and excludes were
+specified in the within section, then the weaver would fail to merge
+them correctly. The conditions for the failure are:
+
+* you need an exclude pattern that the weaver is not optimizing for
+(basically a pattern that could not be matched based upon the typename
+alone, eg. based on whether the type has an annotation)
+* you need two include patterns - one that is being optimized and one
+that is not
+
+These three meet that spec:
+
+[source, xml]
+....
+<include within="*"/>
+<include within="@Foo *"/>
+<exclude within="*Funk*y*"/>
+....
+
+The include="*" can be optimized. The include="@Foo *" is not optimized.
+The exclude="*Funk*y*" is not optimized (this one could be but isn't
+right now as it includes multiple wildcards).
+
+With that configuration any types that the include="*" would have
+accepted are not accepted.
+
+=== Stack overflow problem in ReferenceType.isAssignableFrom()
+
+See https://bugs.eclipse.org/bugs/show_bug.cgi?id=298908[Bug 298908]
+
+This is actually a problem AspectJ has had for a long time, but has
+always proved elusive to recreate. It turns out that it is memory
+related and the more aggressive policy in 1.6.7 causes it to occur much
+more frequently.
+
+The stack trace when this is hit looks like:
+
+[source, text]
+....
+...
+at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
+at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
+at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
+at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
+at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
+at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
+at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
+at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
+at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
+at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
+at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
+...
+....
+
+The weaver has changed over the 1.5 and 1.6 releases and is now reaching
+a point where it really shrinks quite small when not in use (maybe in a
+loadtime environment you have finished loading all your classes). The
+aim is that it can rebuild any required state that is needed later. With
+the move in 1.6.7 from Soft to Weak references, things are being
+discarded much sooner and this is exercising the state rebuilding code
+that wasn't used that often prior to 1.6.7.
+
+The problem is actually because the call on a generic type to get the
+raw type was actually broken and returning the generic type. This then
+loops forever trying to get the raw type from the generic type. This
+happens because the world should store only raw types (which point to
+their generic form) but there was a bug in state rebuilding that instead
+put the generic type directly in the world.
+
+'''''
+
+Thanks to everyone who helped get to the bottom of these problems.
diff --git a/docs/dist/doc/README-1.6.9.adoc b/docs/dist/doc/README-1.6.9.adoc
new file mode 100644
index 000000000..943cc6d90
--- /dev/null
+++ b/docs/dist/doc/README-1.6.9.adoc
@@ -0,0 +1,294 @@
+== AspectJ 1.6.9
+
+_© Copyright 2010 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.6.9 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.6.9;target_milestone=1.6.9M1;target_milestone=1.6.9M2;target_milestone=1.6.9RC1[here]
+
+=== Features
+
+==== declare annotation supports compound signature patterns: https://bugs.eclipse.org/bugs/show_bug.cgi?id=287613[287613]
+
+Until now it wasn't possible to express a compound pattern in any of the
+declare annotation constructs that take a member signature. For example,
+if you wanted to attach an annotation to all your getter like methods,
+you needed two constructs
+
+[source, java]
+....
+declare @method: * is*(): @FooBar;
+declare @method: * get*(): @FooBar;
+....
+
+Now AspectJ allows compound patterns for declare
+@method/@constructor/@field.
+
+[source, java]
+....
+declare @method: (* is*()) || (* get*()): @FooBar;
+....
+
+==== Intertype declaration of member types
+
+It is now possible to ITD member types. The syntax is as would be
+expected. This example introduces a new member type called Inner into
+type Foo:
+
+[source, java]
+....
+public class Foo {
+    public static void main(String[] args) {
+        new Inner().run();
+    }
+}
+
+aspect Magic {
+    public static class Foo.Inner {
+        public void run() {
+            System.out.println("Inner.run() executing");
+        }
+    }
+}
+....
+
+Only static member types are supported.
+
+==== 'Optional' aspects: https://bugs.eclipse.org/bugs/show_bug.cgi?id=310506[310506]
+
+It is not uncommon to ship a library aspect separately to a jar upon
+which it depends. In the case of Spring there is an aspect library
+containing a multitude of aspects that attach different technologies
+(transactions/persistence/etc) to your application. Normally an aspect
+will fail with a "can't find type" style message if a weaver is told to
+use it and yet it references some missing dependency. This can be
+annoying and require you to include jars on your classpath (or in your
+maven configuration) that you don't actually use, they are *only* there
+to avoid problems with the aspect. In 1.6.9 you can add a setting to
+these aspects in the aop.xml that makes them optional. The setting
+mentions a type and if that type cannot be found the aspect immediately
+shuts itself down. This basically means that the aspect is only going to
+do its job if the type being mentioned in the setting is around. This
+enables the aspect library to be on the aspect path but any aspects
+within it to switch-off if there is nothing for them to do.
+
+Here is an example, 'AspectA' will switch itself off if the type
+'a.b.c.Anno' cannot be found:
+
+[source, xml]
+....
+<aspect name="AspectA" requires="a.b.c.Anno"/>
+....
+
+==== Reduction in class file sizes: https://bugs.eclipse.org/bugs/show_bug.cgi?id=312839[312839]
+
+More details here:
+http://andrewclement.blogspot.com/2010/05/aspectj-size-is-important.html
+but basically some work has been done to improve the serialized form of
+aspects. As an example, a compiled Roo petclinic sample (which uses lots
+of aspects and ITDs) is down from 1Meg (AspectJ 1.6.9m2) to 630k
+(AspectJ 1.6.9rc1).
+
+==== Transparent weaving: https://bugs.eclipse.org/bugs/show_bug.cgi?id=309743[309743]
+
+In a further step towards transparent weaving, support for the AjType
+reflection system is now being made optional. This means if intending to
+use the AjTypeSystem to reflect on woven code, then the code must be
+built with the option -makeAjReflectable. This change is being made
+because the reflection supporting metadata that enables the AjTypeSystem
+to work can break other tools that are just using regular reflection on
+the classes. These days many more users are processing classes using
+standard reflection than are using AjTypeSystem. The related bugzilla
+discussing this issue is
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=309743[309743].
+
+==== Overweaving: https://bugs.eclipse.org/bugs/show_bug.cgi?id=293450[293450]
+
+Preliminary support for overweaving was added in AspectJ 1.6.7, but now
+in AspectJ 1.6.9m2 it is much more reliable. Basically it is an
+alternative to reweaving when needing to weave a class multiple times.
+Overweaving can cope with 'other tools' modifying the bytecode in
+between AspectJ weaves, whereas reweaving cannot. More details are in
+the related bugzilla
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=293450[293450] and in this
+http://andrewclement.blogspot.com/2010/05/aspectj-overweaving.html[blog
+article]. A weaver is switched into overweaving mode by the option
+-Xset:overWeaving=true - which can be specified on the command line or
+in the weaver options section of aop.xml. There is still more work to be
+done on this feature - any feedback is welcome.
+
+==== AOP Scoping: https://bugs.eclipse.org/bugs/show_bug.cgi?id=124460[124460]
+
+Another feature that had preliminary support a while ago is aspect
+scoping in aop.xml. This has also been improved in AspectJ1.6.9m2. For
+those not aware of it, it is the ability to specify a scope against
+aspects defined in your loadtime weaving aop.xml file. A scope
+effectively enables the user to limit the applicability of your aspect
+to some subset of all those types included by the weaver include
+section. Why is it needed? It can be useful when taking an aspect that
+did not originally scope itself properly (using a within clause) and
+needing to limit its effect in a load time weaving context. Think of it
+as a within pattern that you can put into the aop.xml that augments all
+the pointcuts defined in the original aspect.
+
+Here is an example:
+
+[source, xml]
+....
+<aspectj>
+  <aspects>
+    <aspect name="X"/>
+    <aspect name="Y" scope="com.foo..*"/>
+  </aspects>
+  <weaver>
+    <include within="com..*"/>
+  </weaver>
+</aspectj>
+....
+
+In this example the weaver include section specifies all the types in
+com..* should be woven and the aspects to be used are X and Y. The new
+'scope' setting on aspect Y's definition allows finer control, and
+specifies that Y should in fact only be applied to com.foo..* types.
+
+==== Message inserts for declare warning/error messages
+
+It is now possible to use joinpoint context in the messages attached to
+declare warning and declare error constructs. Some examples:
+
+[source, java]
+....
+declare warning: execution(* A.m(..)): "joinpoint is {joinpoint}";
+declare warning: execution(* A.m(..)): "joinpoint kind is '{joinpoint.kind}'";
+declare warning: get(int *) && within(A): "joinpoint signature is {joinpoint.signature}";
+declare warning: execution(* A.m(..)): "joinpoint declaring type is {joinpoint.signature.declaringType}";
+declare warning: execution(* A.m(..)): "signature name for method is {joinpoint.signature.name}";
+declare warning: execution(* A.m(..)): "joinpoint location is {joinpoint.sourcelocation.sourcefile}:{joinpoint.sourcelocation.line}";
+declare warning: execution(* A.m(..)): "joinpoint line is '{joinpoint.sourcelocation.line}'";
+
+declare warning: get(int *): "warning is from aspect {advice.aspecttype}";
+declare warning: execution(* A.m(..)): "warning sourcelocation is {advice.sourcelocation.sourcefile}:{advice.sourcelocation.line}";
+....
+
+The syntax is to enclose the relevant key within curly brackets within
+the message. Please raise an enhancement request if you need other keys
+- the set supported so far are all those shown in the example above.
+
+==== declare warning/error for type patterns
+
+It is now possible to use a type pattern with declare warning and
+declare error. For example:
+
+[source, java]
+....
+declare warning: I+ && !hasfield(int i): "Implementations of I are expected to have a int field called i";
+....
+
+==== Type category type patterns
+
+This is the ability to narrow the types of interest so that interfaces
+can be ignored, or inner types, or classes or aspects. There is now a
+new is() construct that enables this:
+
+[source, java]
+....
+execution(* (!is(InnerType)).m(..)) {}
+!within(* && is(InnerType)) {}
+....
+
+Options for use in is() are: ClassType, AspectType, InterfaceType,
+InnerType, AnonymousType, EnumType, AnonymousType.
+
+Note: It is important to understand that "!within(is(InnerType))" and
+"within(!is(InnerType))" are not the same. The latter one is unlikely to
+be what you want to use. For example here:
+
+[source, java]
+....
+class Boo {
+  void foo() {}
+  class Bar {
+    void foo() {}
+  }
+}
+....
+
+Bar.foo() will match within(!is(InnerType)) because within considers all
+surrounding types (so although Bar doesn't match the pattern, the
+surrounding Boo will match it). Bar.foo() will not match
+!within(is(InnerType)) because Bar will match the pattern and then the
+result of that match will be negated.
+
+==== Intertype fields preserve visibility and name
+
+Some users always expect this:
+
+[source, java]
+....
+class C {
+}
+
+aspect X {
+  private int C.someField;
+}
+....
+
+To cause a private field called 'someField' to be added to C. This is
+conceptually what happens during compilation but if any user then later
+attempts to access someField via reflection or runs a javap against the
+class file, they will see that isn't what happens in practice. A public
+member is added with a mangled name. For code attempting to access
+someField built with ajc, the visibility of the declaration will, of
+course, be respected. But for frameworks accessing the code later
+(typically through reflection), it can cause confusion. With AspectJ
+1.6.9 the name and visibility are now preserved. Compile time semantics
+remain the same, it is only the weaving process that has changed to
+produce slightly different output.
+
+Here is the output of javap when that is built with 1.6.8:
+
+[source, java]
+....
+class C extends java.lang.Object{
+    public int ajc$interField$X$someField;
+    C();
+}
+....
+
+Here is the output of javap when that is built with 1.6.9:
+
+[source, java]
+....
+class C extends java.lang.Object{
+    private int someField;
+    C();
+    public static int ajc$get$someField(C);
+    public static void ajc$set$someField(C, int);
+}
+....
+
+The name 'someField' is preserved. The visibility is also preserved but
+because of that we also need to generate some accessors to get at the
+field.
+
+==== AspectJ snapshots in a maven repo
+
+To ease how AspectJ development builds can be consumed, they are now
+placed into a maven repo. When a new version of AspectJ is put into AJDT
+it is also put into the maven.springframework.org repo. The maven
+compatible repo is `maven.springframework.org/snapshot/org/aspectj` -
+and if you browse to it you will see it currently contains 1.6.9 dev
+builds under the name 1.6.9.BUILD-SNAPSHOT. The repo is added with this
+magic:
+
+[source, xml]
+....
+<repository>
+    <id>maven.springframework.org</id>
+    <name>SpringSource snapshots</name>
+    <url>http://maven.springframework.org/snapshot</url>
+</repository>
+....
+
+and then the version to depend upon is: 1.6.9.BUILD-SNAPSHOT
+
+'''''
diff --git a/docs/dist/doc/README-1.7.0.adoc b/docs/dist/doc/README-1.7.0.adoc
new file mode 100644
index 000000000..2437d10ef
--- /dev/null
+++ b/docs/dist/doc/README-1.7.0.adoc
@@ -0,0 +1,125 @@
+== AspectJ 1.7.0
+
+_© Copyright 2011 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.7.0 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.0;[here]
+
+_Release info:_
+
+* _1.7.0 available 2-Jul-2012_
+* _1.7.0.RC1 available 25-May-2012_
+* _1.7.0.M1 available 16-Dec-2011_
+
+=== Notable Changes
+
+==== Java 7 bytecode weaving
+
+The first milestone of 1.7.0 upgraded the compiler but this still left
+the weaver with some issues if it had to weave into bytecode containing
+some of the new features that were allowed by Java 1.7. In particular
+this meant any bytecode containing the INVOKEDYNAMIC (new instruction
+for 1.7) and the related new constant pool entry types that support it.
+RC1 now supports weaving into bytecode containing these features.
+However, the new INVOKEDYNAMIC instruction does not surface as a join
+point yet so you cannot write a pointcut to match on it. If you use
+execution() pointcuts as opposed to call() then you will still be able
+to advise what the invokedynamic actually calls.
+
+==== Bytecode caching for loadtime weaving
+
+Under https://bugs.eclipse.org/bugs/show_bug.cgi?id=367673[bug 367673]
+we have had a contribution (thanks John Kew!) that enables a bytecode
+cache for loadtime weaving. The details and some rudimentary benchmark
+numbers are in the bug. Basically it caches woven bytecode on first
+start of a system using LTW and then reuses that woven bytecode on
+subsequent starts - this saves weaving time and also memory consumption.
+To activate it, use the following system properties:
+
+[source, text]
+....
+-Daj.weaving.cache.enabled=true
+-Daj.weaving.cache.dir=/tmp/aspectj-cache/
+....
+
+==== Upgrade to Java 7
+
+For AspectJ 1.7.0, AspectJ moved from Eclipse JDT Core 0.785_R33x
+(Eclipse 3.3) to Eclipse JDT Core 0.B79_R37x (Eclipse 3.7). This is a
+big change where AspectJ is picking up four years of change from the
+Eclipse compiler.
+
+It means that you can now use the new Java 7 language constructs in your
+programs:
+
+- Diamond operator in advice:
+
+[source, java]
+....
+aspect Foo {
+  before(): execution(* *(..)) {
+    List ls = new ArrayList<>();
+  }
+}
+....
+
+- Diamond operator in ITD:
+
+[source, java]
+....
+public List DiamondITD.ls = new ArrayList<>();
+....
+
+- Underscore literals and binary literals in advice:
+
+[source, java]
+....
+before(): execution(* *(..)) {
+  int onemill = 1_000_000;
+  int four =0b100;
+}
+....
+
+- Multi-catch:``
+
+[source, java]
+....
+before(): execution(* main(..)) {
+  try {
+    foo("abc");
+  } catch (ExceptionA | ExceptionB ex) {
+    bar(ex);
+  }
+}
+....
+
+- String switch:``
+
+[source, java]
+....
+before(String s): execution(* *(..)) && args(s) {
+  switch(s) {
+    case "quux":
+      foo();
+      break;
+    case "bar":
+      foo();
+      break;
+    default:
+      foo();
+      break;
+  }
+}
+....
+
+- Try with resources:``
+
+[source, java]
+....
+try (
+  InputStream in = new FileInputStream(src);
+  OutputStream out = new FileOutputStream(dest))
+{
+  // code
+}
+....
diff --git a/docs/dist/doc/README-1.7.1.adoc b/docs/dist/doc/README-1.7.1.adoc
new file mode 100644
index 000000000..30515f0e2
--- /dev/null
+++ b/docs/dist/doc/README-1.7.1.adoc
@@ -0,0 +1,34 @@
+== AspectJ 1.7.1
+
+_© Copyright 2011 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.7.1 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.1;[here]
+
+_Release info: 1.7.1 available 6-Sep-2012_
+
+=== Changes
+
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=388971[388971] Double
+Synthetic attributes on some around advice members +
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=387718[387718]
+RuntimeException when trying to compile broken code +
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=387568[387568] Warning
+"Xlint:unresolvableMember" for enums +
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=387444[387444] Softening
+exception in try-with-resources +
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=386888[386888] spring-data
+hello-worlds sample fails to compile with 1.7.0 +
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=386337[386337] Light AOP
+Parser does not support declare-annotation +
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=386049[386049] Error "must
+implement abstract inter-type declaration" even though build is fine +
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=384401[384401] NPE when no
+pointcut in afterthrowing annotation style advice +
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=384398[384398] Type
+Mismatch error when using inner classes contained in generic types
+within ITDs +
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=381906[381906] ASPECTJ
+Internal Compiler Error +
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=73507[73507] Public ITD of
+fields on interfaces creates mangled members +
diff --git a/docs/dist/doc/README-1.7.2.adoc b/docs/dist/doc/README-1.7.2.adoc
new file mode 100644
index 000000000..52754ad8e
--- /dev/null
+++ b/docs/dist/doc/README-1.7.2.adoc
@@ -0,0 +1,23 @@
+== AspectJ 1.7.2
+
+_© Copyright 2011 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.7.2 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.2;[here]
+
+_Release info: 1.7.2 available 13-Feb-2013_
+
+=== Fixes:
+
+* Incorrect signature attributes generated into some class files for
+complex generics declarations.
+* Generics information incorrectly being placed in the stackmap
+verification attributes.
+* Problems with generic ITDs not being picked up correctly, resulting in
+'method must be implemented' errors.
+* Problems with multiple usages of 'requires' clause in aop.xml for
+conditional aspects.
+* Generated if() pointcut representations in class files change on only
+a source whitespace change.
+* Intermittent problem with generic ITDs due to weak references being
+collected too soon.
diff --git a/docs/dist/doc/README-1.7.3.adoc b/docs/dist/doc/README-1.7.3.adoc
new file mode 100644
index 000000000..73a0ad320
--- /dev/null
+++ b/docs/dist/doc/README-1.7.3.adoc
@@ -0,0 +1,8 @@
+== AspectJ 1.7.3
+
+_© Copyright 2011 Contributors. All rights reserved._
+
+_Release info: 1.7.3 available 13-Jun-2013_
+
+The list of resolved issues in 1.7.3 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.3;[here]
diff --git a/docs/dist/doc/README-1.7.4.adoc b/docs/dist/doc/README-1.7.4.adoc
new file mode 100644
index 000000000..20464744a
--- /dev/null
+++ b/docs/dist/doc/README-1.7.4.adoc
@@ -0,0 +1,34 @@
+== AspectJ 1.7.4
+
+_© Copyright 2013 Contributors. All rights reserved._
+
+The list of resolved issues in 1.7.4 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.4;[here]
+
+_Release info: 1.7.4 available 24-Oct-2013_
+
+*Notes*
+
+* This release includes an important fix for using loadtime weaving in a
+JVM where JMX is turned on
+(https://bugs.eclipse.org/bugs/show_bug.cgi?id=415266[415266])
+* There are some new message insert keys usable in declare error/warning
+(https://bugs.eclipse.org/bugs/show_bug.cgi?id=420210[420210]) The new
+keys are:
++
+[source, java]
+....
+joinpoint.enclosingclass // Bar
+joinpoint.enclosingmember // void Bar.foo(String)
+joinpoint.enclosingmember.name // foo
+....
++
+All keys are case insensitive.
+* It is now possible to specify individual xlint settings without
+needing to supply a file
+(https://bugs.eclipse.org/bugs/show_bug.cgi?id=419279[419279])
++
+[source, text]
+....
+ajc -Xlint:adviceDidNotMatch=error,noGuardForLazyTjp=ignore Foo.java
+....
diff --git a/docs/dist/doc/README-1.8.0.adoc b/docs/dist/doc/README-1.8.0.adoc
new file mode 100644
index 000000000..9a2ba78be
--- /dev/null
+++ b/docs/dist/doc/README-1.8.0.adoc
@@ -0,0 +1,72 @@
+== AspectJ 1.8.0
+
+_© Copyright 2014 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.8.0 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.0.M1;target_milestone=1.8.0;[here]
+
+_Release info:_
+
+* _1.8.0 available 17-Apr-2014_
+* _1.8.0.RC1 available 18-Mar-2014_
+* _1.8.0.M1 available 29-Jul-2013_
+
+=== Notable changes
+
+==== Java 8 compilation
+
+AspectJ has been updated to the latest available Eclipse Java compiler
+version that compiles Java8 code (the version available as a feature
+patch on top of Eclipse 4.3.2).
+
+Here is a sample AspectJ8 program:
+
+[source, java]
+....
+// === 8< ==== C.java ==== 8< ===
+import java.util.Arrays;
+
+interface I {
+    // Default method
+    default void foo() {
+        System.out.println("ABC");
+    }
+}
+
+public class C implements I{
+    public static void main(String[] args) {
+        new C().foo();
+        // Lambda
+        Runnable r = () -> { System.out.println("hello world!"); };
+        r.run();
+        // Used Java8 b97
+        Arrays.asList(MyClass.doSomething()).forEach((p) -> System.out.println(p));
+    }
+}
+
+aspect X {
+    before(): execution(* I.foo()) {
+        System.out.println("I.foo running");
+    }
+    before(): staticinitialization(!X) {
+        System.out.println("Clazz "+thisJoinPointStaticPart);
+    }
+}
+
+
+class Utils {
+    public static int compareByLength(String in, String out) {
+        return in.length() - out.length();
+    }
+}
+
+class MyClass {
+    public static String[] doSomething() {
+        String []args = new String[]{"4444","333","22","1"};
+        // Method reference
+        Arrays.sort(args,Utils::compareByLength);
+        return args;
+    }
+}
+// === 8< ==== C.java ==== 8< ===
+....
diff --git a/docs/dist/doc/README-1.8.1.adoc b/docs/dist/doc/README-1.8.1.adoc
new file mode 100644
index 000000000..ef0e8a1ee
--- /dev/null
+++ b/docs/dist/doc/README-1.8.1.adoc
@@ -0,0 +1,16 @@
+== AspectJ 1.8.1
+
+_© Copyright 2014 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.8.1 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.1;[here]
+
+_Release info: 1.8.1 available 20-Jun-2014_
+
+=== Notable changes
+
+==== Java 8 update
+
+As Eclipse itself nears the 4.4 release, AspectJ has been updated to the
+latest Eclipse JDT Core that will be included in it, picking up numerous
+Java8 related fixes.
diff --git a/docs/dist/doc/README-1.8.10.adoc b/docs/dist/doc/README-1.8.10.adoc
new file mode 100644
index 000000000..cce5da187
--- /dev/null
+++ b/docs/dist/doc/README-1.8.10.adoc
@@ -0,0 +1,37 @@
+== AspectJ 1.8.10
+
+_© Copyright 2016 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.8.10 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.10;[here]
+
+_Release info: 1.8.10 available 9-Dec-2016_
+
+=== Notable changes
+
+==== JDT Upgrade
+
+The JDT compiler inside AspectJ has been upgraded to the Eclipse Neon.2
+level (JDT commit #75dbfad0).
+
+==== Java8
+
+The Eclipse JDT compiler embedded inside AspectJ now requires Java 8, so
+that is the minimum required level to compile sources with AspectJ.
+However, if only doing weaving and no compilation then it is possible to
+use Java 7.
+
+==== Annotation style around advice and proceed (https://bugs.eclipse.org/bugs/show_bug.cgi?id=500035[Bug 500035])
+
+A long standing issue that has been lurking in the handling of arguments
+passed to proceed for annotation style aspects has been fixed. If, at a
+joinpoint where 'this'/'target' differ (for example at some call
+joinpoints), the pointcut bound either 'this' or 'target' (but not
+both), then the system would still expect the advice to pass both 'this'
+and 'target' into the proceed call. With the fix here you only need to
+pass what you bind. So if you bind only 'this' you don't need to pass
+'target' (and vice versa). This will affect users that have been working
+around this quirk by passing both 'this' and 'target'. That isn't
+necessary anymore. This fix is in aspectjrt.jar so you will need to be
+using the 1.8.10 version of aspectjrt.jar at runtime to pickup this
+change.
diff --git a/docs/dist/doc/README-1.8.11.adoc b/docs/dist/doc/README-1.8.11.adoc
new file mode 100644
index 000000000..dedbc0463
--- /dev/null
+++ b/docs/dist/doc/README-1.8.11.adoc
@@ -0,0 +1,19 @@
+== AspectJ 1.8.11
+
+_© Copyright 2017 Contributors. All rights reserved._
+
+_Release info: 1.8.11 available 26-Sep-2017_
+
+This release is a small compatibility release to improve the behaviour
+of the AspectJ 1.8 line on JDK9. Importantly it includes a change that
+knows about the Java 9 version information and so does not get confused
+and think it is running on something really old (which typically
+manifests as it complaining about annotations not being supported on
+this level of Java).
+
+With that change this release is usable for Spring AOP use cases because
+that is doing runtime pointcut matching with proxy creation rather than
+actual weaving. Although if you using Spring AOP with class level
+annotation retention there may still be issues. If you experience
+problems or need to do actual weaving on JDK9, please use AspectJ9
+instead.
diff --git a/docs/dist/doc/README-1.8.2.adoc b/docs/dist/doc/README-1.8.2.adoc
new file mode 100644
index 000000000..a49213617
--- /dev/null
+++ b/docs/dist/doc/README-1.8.2.adoc
@@ -0,0 +1,162 @@
+== AspectJ 1.8.2
+
+_© Copyright 2014 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.8.2 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.2;[here]
+
+_Release info: 1.8.2 available 14-Aug-2014_
+
+=== Notable changes
+
+Although only a few bugs have been fixed here, they are quite important
+ones:
+
+==== Update to more recent Eclipse Compiler
+
+AspectJ is now based on a more up to date Eclipse compiler level (git
+hash 2b07958) so includes all the latest fixes
+
+==== Correct handling of RuntimeInvisibleTypeAnnotations (type annotations without runtime visibility)
+
+For anyone weaving code containing these kind of type annotations, this
+is an important fix. Although AspectJ does not currently support
+pointcuts matching on these kinds of annotation it was crashing when
+they were encountered. That is now fixed.
+
+==== Annotation processing
+
+A very long standing issue, the AspectJ compiler now supports annotation
+processors thanks to some work by Sergey Stupin.
+
+Here is a short example, a very basic annotation and application:
+
+===== Marker.java
+
+[source, java]
+....
+import java.lang.annotation.Retention;
+import java.lang.annotation.RetentionPolicy;
+
+@Retention(RetentionPolicy.RUNTIME)
+public @interface Marker { }
+....
+
+===== Code.java
+
+[source, java]
+....
+public class Code {
+
+  public static void main(String []argv) {
+    new Code().moo();
+    new Code().boo();
+    new Code().too();
+    new Code().woo();
+  }
+
+  public void moo() {}
+
+  @Marker
+  public void boo() {}
+
+  @Marker
+  public void too() {}
+
+  public void woo() {}
+}
+....
+
+And now a basic annotation processor. This processor will find methods
+in the source marked with the annotation Marker and for each one
+generate an aspect tailored to advising that method (this *is* a
+contrived demo!)
+
+===== DemoProcessor.java
+
+[source, java]
+....
+import java.io.*;
+import javax.tools.*;
+import java.util.*;
+import javax.annotation.processing.*;
+import javax.lang.model.*;
+import javax.lang.model.element.*;
+
+@SupportedAnnotationTypes(value= {"*"})
+@SupportedSourceVersion(SourceVersion.RELEASE_6)
+public class DemoProcessor extends AbstractProcessor {
+
+  private Filer filer;
+
+  @Override
+  public void init(ProcessingEnvironment env) {
+    filer = env.getFiler();
+  }
+
+  @Override
+  public boolean process(Set elements, RoundEnvironment env) {
+    // Discover anything marked with @Marker
+    for (Element element: env.getElementsAnnotatedWith(Marker.class)) {
+      if (element.getKind() == ElementKind.METHOD) {
+        // For any methods we find, create an aspect:
+        String methodName = element.getSimpleName().toString();
+        String aspectText =
+            "public aspect Advise_"+methodName+" {\n"+
+            "  before(): execution(* "+methodName+"(..)) {\n"+
+            "    System.out.println(\""+methodName+" running\");\n"+
+            "  }\n"+
+            "}\n";
+        try {
+          JavaFileObject file = filer.createSourceFile("Advise_"+methodName, element);
+          file.openWriter().append(aspectText).close();
+          System.out.println("Generated aspect to advise "+element.getSimpleName());
+        } catch (IOException ioe) {
+          // already creates message can appear if processor runs more than once
+          if (!ioe.getMessage().contains("already created")) {
+            ioe.printStackTrace();
+          }
+        }
+      }
+    }
+    return true;
+  }
+}
+....
+
+With those sources, we compile the processor:
+
+[source, text]
+....
+ajc -1.6 DemoProcessor.java Marker.java
+....
+
+Now compile the code with the processor specified:
+
+[source, text]
+....
+ajc -1.6 -processor DemoProcessor -showWeaveInfo Code.java Marker.java
+....
+
+[source, text]
+....
+Generated aspect to advise too
+Generated aspect to advise boo
+Join point 'method-execution(void Code.boo())' in Type 'Code' (Code.java:14) advised by before advice from 'Advise_boo' (Advise_boo.java:2)
+Join point 'method-execution(void Code.too())' in Type 'Code' (Code.java:17) advised by before advice from 'Advise_too' (Advise_too.java:2)
+....
+
+Notice the processor generates the aspects and then they are woven into
+the code being compiled immediately.
+
+Finally we can run it:
+
+[source, text]
+....
+java Code
+boo running
+too running
+....
+
+*Note:* There is still work to be done to get annotation processors
+behaving under AJDT.
diff --git a/docs/dist/doc/README-1.8.3.adoc b/docs/dist/doc/README-1.8.3.adoc
new file mode 100644
index 000000000..0d114d1f2
--- /dev/null
+++ b/docs/dist/doc/README-1.8.3.adoc
@@ -0,0 +1,118 @@
+== AspectJ 1.8.3
+
+_© Copyright 2014 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.8.3 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.3;[here]
+
+_Release info: 1.8.3 available 22-Oct-2014_
+
+=== Notable changes
+
+==== Conditional aspect activation with @RequiredTypes - https://bugs.eclipse.org/bugs/show_bug.cgi?id=436653[Issue 436653]
+
+AspectJ is sometimes used to create aspect libraries. These libraries
+contain a number of aspects often covering a variety of domains. The
+library might typically be available as a jar and contains a single
+aop.xml file that names all the aspects. The library is then consumed by
+some application. However, the application may not need to use all those
+aspects but because they are listed in the aop.xml they will be
+'active'. Now the pointcuts in those unused aspects may not match
+anything in the application and could be considered harmless but the
+pointcuts and the aspects themselves may have references to types in
+other libraries that the application does not have around. This can lead
+to unhelpful "can't find type" messages and currently requires the user
+to add unnecessary entries to their build dependencies just to keep the
+unused aspects happy.
+
+With AspectJ 1.8.3 it is now possible to express a constraint on an
+aspect. The @RequiredTypes annotation specifies one or more fully
+qualified types that must be discoverable on the classpath in order for
+the aspect to activate. Using this there is no need to add those
+extraneous dependencies to an applications build classpath.
+
+Example:
+
+[source, java]
+....
+import org.aspectj.lang.annotation.*;
+
+@RequiredTypes("com.foo.Bar")
+public aspect Foo {
+  before(): execution(@com.foo.Bar * *(..)) {}
+}
+....
+
+If the above aspect is listed in an aop.xml for loadtime weaving or
+passed on the aspectpath for compile time weaving, if the type
+'com.foo.Bar' is not accessible on the classpath then the aspect will be
+turned off and the pointcut will have no effect. There will be no
+attempt made to match it and so no unhelpful "can't find type" messages.
+
+==== cflow and the pre-initialization joinpoint changes due to Java 7 verifier modifications - https://bugs.eclipse.org/bugs/show_bug.cgi?id=443477[Issue 443477]
+
+There has been a change in the Java7 verifier in a recent patch release
+of Java7 (update 67) that causes a verify error for usage of a
+particular AspectJ construct. The problem occurs if you are using cflow
+and it hits the preinitialization join point. The pattern of code
+generated in that case causes the verifyerror. In this release of
+AspectJ we have taken the 'quick' approach to solving this, namely to
+avoid advising preinitialization with the cflow construct. This problem
+appears to come up when the aspect is non-optimal anyway and hitting
+preinitialization was never really intended by the pointcut writer. For
+example:
+
+[source, java]
+....
+execution(* foo(..)) && cflow(within(Bar))
+....
+
+The use of cflow and within there will actually hit *a lot* of
+joinpoints, many of which the user probably didn't mean to. It feels
+like we actually need a warning to indicate the pointcut is probably
+suboptimal. What the user probably meant was something more like this:
+
+[source, java]
+....
+execution(* foo(..)) && cflow(execution(* Bar.*(..))
+....
+
+or
+
+[source, java]
+....
+execution(* foo(..)) && cflow(within(Bar) && execution(* *(..)))
+....
+
+But even if they did want the less optimal form of cflow there still
+seems little use in applying it to pre-initialization - that is your cue
+to raise an AspectJ bug with a realistic use case inside that proves
+this an invalid assumption :)
+
+==== around advice and lambdas - https://bugs.eclipse.org/bugs/show_bug.cgi?id=445395[Issue 445395]
+
+For optimal performance, where possible, AspectJ tries to inline around
+advice when it applies at a joinpoint. There are few characteristics of
+a joinpoint match that can prevent this but we do try to inline where we
+can (the inlining can be manually turned off via -XnoInline).
+
+Inlining of around advice basically means copying the advice
+instructions into the target class. This causes a problem when the
+advice uses lambdas. Lambda usage is currently implemented in java
+compilers by generating invokedynamic bytecode instructions that
+reference bootstrap methods created in the class and a helper method
+generated in the class containing the lambda code. When the
+invokedynamic is encountered at runtime, some magic happens and the
+bootstrap method is used to generate a class on the fly that calls the
+particular lambda method. All this 'extra stuff' breaks the basic
+inlining algorithm that simply copies the advice bytecode into the
+target. Effectively the inlining process needs to become much more
+sophisticated and copy the bootstrap methods and the lambda helper
+methods, avoiding clashes with existing bootstrap/helpers in the target.
+
+Prior to AspectJ 1.8.3 when the inlining failed you would get a horrible
+class cast exception that mentions constant pool entries (because the
+bootstrap method hadn't been copied over to the target). Temporarily in
+1.8.3 we are turning off inlining of around advice containing lambdas,
+which will at least avoid the failure, with the longer term goal of
+improving the inlining process to do all the necessary extra work.
diff --git a/docs/dist/doc/README-1.8.4.adoc b/docs/dist/doc/README-1.8.4.adoc
new file mode 100644
index 000000000..655d74a85
--- /dev/null
+++ b/docs/dist/doc/README-1.8.4.adoc
@@ -0,0 +1,29 @@
+== AspectJ 1.8.4
+
+_© Copyright 2014 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.8.4 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.4;[here]
+
+_Release info: 1.8.4 available 6-Nov-2014_
+
+=== Notable changes
+
+==== Support for is(FinalType)
+
+AspectJ has had type category type patterns since version 1.6.9, see the
+https://www.eclipse.org/aspectj/doc/released/README-1.6.9.html[README].
+This enabled pointcuts to include is(..) clauses to specify which kinds
+of type they were or were not interested in matching, e.g. !within(* &&
+is(InnerType)) means not within innertypes. In 1.8.4 it is now possible
+to recognize (for inclusion or exclusion) final types with
+is(FinalType).
+
+==== thisAspectInstance correctly handled with -1.8
+
+This is the key fix in this release. Some products based on AspectJ were
+using the thisAspectInstance feature (see
+https://www.eclipse.org/aspectj/doc/released/README-1.6.12.html[README
+1.6.12] for more info on the feature). Unfortunately if specifying -1.8
+compliance and using the feature an error would be reported at compile
+time of the aspect. This is now fixed.
diff --git a/docs/dist/doc/README-1.8.5.adoc b/docs/dist/doc/README-1.8.5.adoc
new file mode 100644
index 000000000..22fdcee3f
--- /dev/null
+++ b/docs/dist/doc/README-1.8.5.adoc
@@ -0,0 +1,14 @@
+== AspectJ 1.8.5
+
+_© Copyright 2015 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.8.5 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.5;[here]
+
+_Release info: 1.8.5 available 28-Jan-2015_
+
+=== Notable changes
+
+The most important fixes in 1.8.5 are JDT compiler fixes that it
+includes
+(https://bugs.eclipse.org/bugs/show_bug.cgi?id=455277[455277],https://bugs.eclipse.org/bugs/show_bug.cgi?id=458660[458660]).
diff --git a/docs/dist/doc/README-1.8.6.adoc b/docs/dist/doc/README-1.8.6.adoc
new file mode 100644
index 000000000..9a2129414
--- /dev/null
+++ b/docs/dist/doc/README-1.8.6.adoc
@@ -0,0 +1,8 @@
+== AspectJ 1.8.6
+
+_© Copyright 2015 Contributors. All rights reserved._
+
+_Release info: 1.8.6 available 5-Jun-2015_
+
+The full list of resolved issues in 1.8.6 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.6;[here]
diff --git a/docs/dist/doc/README-1.8.7.adoc b/docs/dist/doc/README-1.8.7.adoc
new file mode 100644
index 000000000..5d4c0de6b
--- /dev/null
+++ b/docs/dist/doc/README-1.8.7.adoc
@@ -0,0 +1,127 @@
+== AspectJ 1.8.7
+
+_© Copyright 2015 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.8.7 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.7;[here]
+
+_Release info: 1.8.7 available 9-Sep-2015_
+
+=== Notable changes
+
+==== ajdoc
+
+The ajdoc tool has been fixed! It is now working again if run on a 1.7
+JDK.
+
+==== Dynamic weaver attachment
+
+The AspectJ loadtime weaving agent can now be dynamically attached to a
+JVM after it has started (you don't need to use -javaagent). This offers
+extra flexibility but obviously any classes loaded before attachment
+will not be woven.
+
+Here is a simple aspect:
+
+[source, java]
+....
+public aspect Azpect {
+  before(): execution(* *(..)) {
+    System.out.println(thisJoinPointStaticPart);
+  }
+}
+....
+
+Compiled via:
+
+[source, text]
+....
+ajc -1.8 Azpect.java -outxml
+....
+
+This produces a compiled class Azpect.class and a file
+META-INF/aop-ajc.xml.
+
+I then have this sample application (same directory):
+
+[source, java]
+....
+import java.lang.management.ManagementFactory;
+import org.aspectj.weaver.loadtime.Agent;
+import com.sun.tools.attach.VirtualMachine;
+
+public class Application {
+
+  public static void main(String[] args) {
+    if (!isAspectJAgentLoaded())
+      System.err.println("WARNING: AspectJ weaving agent not loaded");
+    new Sample().doSomething();
+  }
+
+  public static boolean isAspectJAgentLoaded() {
+    try {
+      Agent.getInstrumentation();
+    } catch (NoClassDefFoundError e) {
+      System.out.println(e);
+      return false;
+    } catch (UnsupportedOperationException e) {
+      System.out.println(e);
+      return dynamicallyLoadAspectJAgent();
+    }
+    return true;
+  }
+
+  public static boolean dynamicallyLoadAspectJAgent() {
+    String nameOfRunningVM = ManagementFactory.getRuntimeMXBean().getName();
+    int p = nameOfRunningVM.indexOf('@');
+    String pid = nameOfRunningVM.substring(0, p);
+    try {
+      VirtualMachine vm = VirtualMachine.attach(pid);
+      String jarFilePath = System.getProperty("AGENT_PATH");
+      vm.loadAgent(jarFilePath);
+      vm.detach();
+    } catch (Exception e) {
+      System.out.println(e);
+      return false;
+    }
+    return true;
+  }
+}
+....
+
+And this Sample class:
+
+[source, java]
+....
+public class Sample {
+    public void doSomething() {
+        System.out.println("Do something");
+        System.out.println("Square of 7 = " + square(7));
+    }
+
+    private int square(int i) {
+        return i * i;
+    }
+}
+....
+
+Compile these with javac, *but you must have the aspectjweaver and the
+JDK tools.jar on your classpath*.
+
+Once compiled we can run it:
+
+[source, text]
+....
+java -DAGENT_PATH=<path-to>/aspectjweaver.jar Application
+....
+
+What does it do? The main method calls the function that detects whether
+the agent is attached, if it is not then it programmatically attaches it
+using the VirtualMachine class. Then the main method accesses the Sample
+class. At this point in program execution the Sample class is loaded and
+because the agent has been attached it gets woven. Notice that the
+Application class itself is not woven because it was loaded prior to
+agent attachment.
+
+Thanks to Alexander Kriegisch for the sample code and the patch to add
+this behaviour to AspectJ.
diff --git a/docs/dist/doc/README-1.8.8.adoc b/docs/dist/doc/README-1.8.8.adoc
new file mode 100644
index 000000000..12b59eeb9
--- /dev/null
+++ b/docs/dist/doc/README-1.8.8.adoc
@@ -0,0 +1,17 @@
+== AspectJ 1.8.8
+
+_© Copyright 2016 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.8.8 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.8;[here]
+
+_Release info: 1.8.8 available 7-Jan-2016_
+
+=== Notable changes
+
+==== Around advice on default methods
+
+In previous releases attempting to apply around advice to default
+methods would create methods with rogue modifiers in the interface
+declaring the default method (loading these interfaces would then result
+in a verifier error). This has now been fixed.
diff --git a/docs/dist/doc/README-1.8.9.adoc b/docs/dist/doc/README-1.8.9.adoc
new file mode 100644
index 000000000..f24bb1223
--- /dev/null
+++ b/docs/dist/doc/README-1.8.9.adoc
@@ -0,0 +1,13 @@
+== AspectJ 1.8.9
+
+_© Copyright 2016 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.8.9 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.9;[here]
+
+_Release info: 1.8.9 available 14-Mar-2016_
+
+=== Notable changes
+
+The JDT compiler inside AspectJ has been upgraded to the Eclipse Mars.2
+level (commit #a7bba8b1).
diff --git a/docs/dist/doc/README-1.9.0.adoc b/docs/dist/doc/README-1.9.0.adoc
new file mode 100644
index 000000000..06872691c
--- /dev/null
+++ b/docs/dist/doc/README-1.9.0.adoc
@@ -0,0 +1,341 @@
+== AspectJ 1.9.0
+
+_© Copyright 2018 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.9.0 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.0[here]
+
+_Release info: 1.9.0 available 2-Apr-2018_
+
+=== Improved runtime interface
+
+New factory methods have been added to the AspectJ runtime. This is an
+attempt to more optimally create `thisJoinPoint` and
+`thisEnclosingJoinPoint` objects. The generated code that invokes these
+now also uses the ability for the `LDC` bytecode instruction to load class
+constants directly (this replaces what was happening previously where
+generated code referenced string class names and class-loading was being
+done from the AspectJ runtime as the woven application was starting).
+
+This is turned on by using `-Xajruntimetarget:1.9`. This option was used
+previously to enable users to target an old runtime if they knew that
+old runtime is all that was available at some deployed target. The new
+generation mechanism is not the default, not until it has had a bit more
+testing out in the wild.
+
+The changes to generated code have a couple of potential side effects:
+
+* *overall size*: the woven code may be smaller due to the use of
+smaller string constant pieces in the generated code (previously strings
+were smashed together in the generated code and then taken apart by
+AspectJ at runtime). Since the pieces are smaller, they can be shared
+across other uses in the class file.
+* *method size*: although the overall class may be smaller there are
+more instructions involved in preparing the data for invocation of the
+new joinpoint factory methods. It is possible if you have a lot of
+joinpoints that we might blow the 64k instruction limit for the
+`ajc$preClinit` method (where the factory invocation code is generated).
+Please provide feedback if this happens to you!
+
+In anticipation of not all build plugins supporting that
+`-Xajruntimetarget` option, you can now specify these kinds of option in
+the `ASPECTJ_OPTS` environment variable. Set that in your environment:
+
+[source, text]
+....
+export ASPECTJ_OPTS="-Xajruntimetarget:1.9"
+....
+
+And it should get picked up by AspectJ when it runs.
+
+== AspectJ 1.9.0.RC4
+
+_Release info: 1.9.0.RC4 available 21-Feb-2018_
+
+Primary changes in RC4 are to add support for `<compilerArg>` in the Ant
+task. This enables users of the Ant task to pass in options supported by
+the underlying AspectJ but not yet surfaced elsewhere. Particularly
+useful with Java9 which includes a number of module related commands.
+For example, here is an `iajc` usage with `compilerArg` that is passing
+`--add-modules java.xml.bind`:
+
+[source, xml]
+....
+<iajc destdir="bin" failonerror="true"
+  showWeaveInfo="true" source="1.9" target="1.9"
+  debug="true"  fork="true" maxmem="256m">
+
+  <compilerArg value="--add-modules"/>
+  <compilerArg value="java.xml.bind"/>
+  <src path="src" />
+  <classpath>
+    <pathelement location="${aspectj.home}/lib/aspectjrt.jar"/>
+  </classpath>
+
+</iajc>
+....
+
+== AspectJ 1.9.0.RC3
+
+_Release info: 1.9.0.RC3 available 5-Feb-2018_
+
+Primary changes in RC3 are to upgrade JDT and pickup all the fixes for
+Java9 that have gone into it over the last few months.
+
+== AspectJ 1.9.0.RC2
+
+_Release info: 1.9.0.RC2 available 9-Nov-2017_
+
+Key change in 1.9.0.RC2 is actually to be more tolerant of JDK10. The
+version handling has been somewhat overhauled so AspectJ 9 will behave
+better on Java 10 and future JDKs. This should put AspectJ in a better
+place if new JDK versions are going to arrive thick and fast.
+
+== AspectJ 1.9.0.RC1
+
+_Release info: 1.9.0.RC1 available 20-Oct-2017_
+
+This is the first release candidate of AspectJ 1.9.0 - the version of
+AspectJ to be based on Java9. It includes a recent version of the
+Eclipse Java9 compiler (from jdt core, commit #062ac5d7a6bf9).
+
+=== Automatic Modules
+
+AspectJ can now be used with the new module system available in Java9.
+The key jars in AspectJ have been given automatic module names. The
+automatic module name is `org.aspectj.runtime` for the `aspectjrt` module:
+
+[source, text]
+....
+$ java --module-path <pathto>/lib/aspectjrt.jar --list-modules | grep aspectj
+
+org.aspectj.runtime file:///<pathto>/lib/aspectjrt.jar automatic
+....
+
+And similarly `org.aspectj.weaver` and `org.aspectj.tools` for `aspectjweaver`
+and `aspectjtools`, respectively:
+
+[source, text]
+....
+$ java --module-path <pathto>/lib/aspectjweaver.jar --describe-module org.aspectj.weaver
+
+org.aspectj.weaver file:///<pathto>/lib/aspectjweaver.jar automatic
+requires java.base mandated
+contains aj.org.objectweb.asm
+contains aj.org.objectweb.asm.signature
+contains org.aspectj.apache.bcel
+contains org.aspectj.apache.bcel.classfile
+contains org.aspectj.apache.bcel.classfile.annotation
+contains org.aspectj.apache.bcel.generic
+contains org.aspectj.apache.bcel.util
+contains org.aspectj.asm
+contains org.aspectj.asm.internal
+...
+....
+
+=== Building woven modules
+
+AspectJ understands `module-info.java` source files and building modules
+that include aspects. Here is an example:
+
+[source, java]
+....
+// module-info.java
+
+module demo {
+  exports pkg;
+  requires org.aspectj.runtime;
+}
+
+// pkg/Demo.java
+
+package pkg;
+
+public class Demo {
+  public static void main(String[] argv) {
+    System.out.println("Demo running");
+  }
+}
+
+// otherpkg/Azpect.java
+
+package otherpkg;
+
+public aspect Azpect {
+  before(): execution(* *(..)) && !within(Azpect) {
+    System.out.println("Azpect running");
+  }
+}
+....
+
+We can now build those into a module:
+
+[source, text]
+....
+$ ajc -1.9 module-info.java otherpkg/Azpect.java pkg/Demo.java -outjar demo.jar
+
+...
+module-info.java:3 [error] org.aspectj.runtime cannot be resolved to a module
+...
+....
+
+Wait, that failed! Yes, `aspectjrt.jar` (which includes the required
+`org.aspectj.weaver` module) wasn't supplied. We need to pass it on the
+module-path:
+
+[source, text]
+....
+$ ajc -1.9 --module-path <pathto>/aspectjrt.jar module-info.java otherpkg/Azpect.java pkg/Demo.java -outjar demo.jar
+....
+
+Now we have a demo module we can run:
+
+[source, text]
+....
+$ java --module-path <pathto>/aspectjrt.jar:demo.jar --module demo/pkg.Demo
+
+Azpect running
+Demo running
+....
+
+That's it!
+
+=== Binary weaving with modules
+
+A module is really just a jar with a _module-info_ descriptor. As such, you
+can simply pass a module on the _inpath_ and binary-weave it with other
+aspects. Take the module we built above, let's weave into it again:
+
+[source, java]
+....
+// extra/AnotherAzpect.java
+
+package extra;
+
+public aspect AnotherAzpect {
+  before(): execution(* *(..)) && !within(*Azpect) {
+    System.out.println("AnotherAzpect running");
+  }
+}
+....
+
+[source, text]
+....
+$ ajc -inpath demo.jar AnotherAzpect.java -outjar newdemo.jar
+....
+
+Notice how there was no complaint here that the `org.aspectj.runtime`
+module hadn't been passed in. That is because inpath was being used
+which doesn't treat specified jars as modules (and so does not check
+dependencies). There is no _module-inpath_ right now.
+
+Because the new JAR produced includes the compiled aspect, the
+_module-info_ specification inside is still correct, so we can run it
+exactly as before:
+
+[source, text]
+....
+$ java --module-path ~/installs/aspectj190rc1/lib/aspectjrt.jar:newdemo.jar --module demo/pkg.Demo
+
+Azpect running
+AnotherAzpect running
+Demo running
+....
+
+=== Faster Spring AOP
+
+Dave Syer recently created a https://github.com/dsyer/spring-boot-aspectj[series of benchmarks] for checking the speed
+of Spring-AspectJ.
+
+Here we can see the numbers for AspectJ 1.8.11 (on an older Macbook
+Pro):
+
+[source, text]
+....
+Benchmark                 (scale)  Mode  Cnt   Score   Error  Units
+StartupBenchmark.ltw          N/A  avgt   10   2.553 ~ 0.030   s/op
+StartupBenchmark.ltw_100      N/A  avgt   10   2.608 ~ 0.046   s/op
+StartupBenchmark.spring     v0_10  avgt   10   2.120 ~ 0.148   s/op
+StartupBenchmark.spring     v1_10  avgt   10   2.219 ~ 0.066   s/op
+StartupBenchmark.spring    v1_100  avgt   10   2.244 ~ 0.030   s/op
+StartupBenchmark.spring    v10_50  avgt   10   2.950 ~ 0.026   s/op
+StartupBenchmark.spring    v20_50  avgt   10   3.854 ~ 0.090   s/op
+StartupBenchmark.spring   v20_100  avgt   10   4.003 ~ 0.038   s/op
+StartupBenchmark.spring     a0_10  avgt   10   2.067 ~ 0.019   s/op
+StartupBenchmark.spring     a1_10  avgt   10   2.724 ~ 0.023   s/op
+StartupBenchmark.spring    a1_100  avgt   10   2.778 ~ 0.057   s/op
+StartupBenchmark.spring    a10_50  avgt   10   7.191 ~ 0.134   s/op
+StartupBenchmark.spring   a10_100  avgt   10   7.191 ~ 0.168   s/op
+StartupBenchmark.spring    a20_50  avgt   10  11.541 ~ 0.158   s/op
+StartupBenchmark.spring   a20_100  avgt   10  11.464 ~ 0.157   s/op
+....
+
+So this is the average startup of an app affected by aspects applying to
+the beans involved. Where numbers are referenced the first is the number
+of aspects/pointcuts and the second is the number of beans. The 'a'
+indicates an annotation based pointcut vs a non-annotation based
+pointcut ('v'). Notice things are much worse for annotation based
+pointcuts. At 20 pointcuts and 50 beans the app is 9 seconds slower to
+startup. +
+
+In AspectJ 1.8.12 and 1.9.0.RC1 some work has been done here. The key
+change is to recognize that the use of annotations with runtime
+retention is much more likely than annotations with class level
+retention. Retrieving annotations with class retention is costly because
+we must open the bytes for the class file and dig around in there (vs
+runtime retention which are immediately accessible by reflection on the
+types). In 1.8.11 the actual type of the annotation involved in the
+matching is ignored and the code will fetch *all* the annotations on the
+type/method/field being matched against. So even if the match is looking
+for a runtime retention annotation, we were doing the costly thing of
+fetching any class retention annotations. In 1.8.12/1.9.0.RC1 we take
+the type of the match annotation into account - allowing us to skip
+opening the classfiles in many cases. There is also some deeper work on
+activating caches that were not previously being used correctly but the
+primary change is factoring in the annotation type.
+
+What difference does that make? AspectJ 1.9.0.RC1:
+
+[source, text]
+....
+Benchmark                 (scale)  Mode  Cnt  Score   Error  Units
+StartupBenchmark.ltw          N/A  avgt   10  2.568 ~ 0.035   s/op
+StartupBenchmark.ltw_100      N/A  avgt   10  2.622 ~ 0.075   s/op
+StartupBenchmark.spring     v0_10  avgt   10  2.096 ~ 0.054   s/op
+StartupBenchmark.spring     v1_10  avgt   10  2.206 ~ 0.031   s/op
+StartupBenchmark.spring    v1_100  avgt   10  2.252 ~ 0.025   s/op
+StartupBenchmark.spring    v10_50  avgt   10  2.979 ~ 0.071   s/op
+StartupBenchmark.spring    v20_50  avgt   10  3.851 ~ 0.058   s/op
+StartupBenchmark.spring   v20_100  avgt   10  4.000 ~ 0.046   s/op
+StartupBenchmark.spring     a0_10  avgt   10  2.071 ~ 0.026   s/op
+StartupBenchmark.spring     a1_10  avgt   10  2.182 ~ 0.032   s/op
+StartupBenchmark.spring    a1_100  avgt   10  2.272 ~ 0.024   s/op
+StartupBenchmark.spring    a10_50  avgt   10  2.557 ~ 0.027   s/op
+StartupBenchmark.spring   a10_100  avgt   10  2.598 ~ 0.040   s/op
+StartupBenchmark.spring    a20_50  avgt   10  2.961 ~ 0.043   s/op
+StartupBenchmark.spring   a20_100  avgt   10  3.093 ~ 0.098   s/op
+....
+
+Look at the a20_100 case - instead of impacting start time by 9 seconds,
+it impacts it by 1 second.
+
+=== More to come...
+
+* Eclipse JDT Java 9 support is still being actively worked on and lots
+of fixes will be coming through over the next few months and included in
+AspectJ 1.9.X revisions.
+
+* AspectJ does not currently modify `module-info.java` files. An aspect
+from one module applying to code in another module clearly introduces a
+dependency between those two modules. There is no reason - other than
+time! - that this can't be done.
+(https://bugs.eclipse.org/bugs/show_bug.cgi?id=526244[Issue 526244])
+
+* Related to that AspectJ, on detection of aspects should be able to
+automatically introduce the `requires org.aspectj.runtime` to the
+_module-info_. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=526242[Issue
+526242])
+
+* Module-aware variants of AspectJ paths: `--module-inpath`,
+`--module-aspectpath`.
+(https://bugs.eclipse.org/bugs/show_bug.cgi?id=526243[Issue 526243])
diff --git a/docs/dist/doc/README-1.9.1.adoc b/docs/dist/doc/README-1.9.1.adoc
new file mode 100644
index 000000000..e5aeac249
--- /dev/null
+++ b/docs/dist/doc/README-1.9.1.adoc
@@ -0,0 +1,31 @@
+== AspectJ 1.9.1
+
+_© Copyright 2018 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.9.1 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.1[here]
+
+_Release info: 1.9.1 available 20-Apr-2018_
+
+=== Java 10 support
+
+AspectJ has updated to a recent JDT compiler version (commit
+#abe06abe4ce1 - 9-Apr-2018). With this update it now supports Java10.
+This means you can use the `var` support. A simple example of combining
+var with an aspect:
+
+[source, java]
+....
+public class Code3 {
+  public static void main(String []argv) {
+    var x = "hello";
+    System.out.println(x.getClass());
+  }
+}
+
+aspect X {
+  before(): call(* *.getClass()) && target(String) {
+    System.out.println(thisJoinPointStaticPart);
+  }
+}
+....
diff --git a/docs/dist/doc/README-1.9.19.adoc b/docs/dist/doc/README-1.9.19.adoc
new file mode 100644
index 000000000..07618a02c
--- /dev/null
+++ b/docs/dist/doc/README-1.9.19.adoc
@@ -0,0 +1,92 @@
+== AspectJ 1.9.19
+
+_© Copyright 2022 Contributors. All rights reserved._
+
+== AspectJ 1.9.19
+
+_© Copyright 2022 Contributors. All rights reserved._
+
+_Release info: 1.9.19 available 21-Dec-2022_
+
+Please note that Bugzilla for issue management is deprecated and new issues should be filed as
+https://github.com/eclipse/org.aspectj/issues/new[GitHub issues]. The list of issues addressed for 1.9.19 can be found
+here:
+
+* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.19[GitHub 1.9.19]
+* https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.19[Bugzilla 1.9.19]
+
+=== New features
+
+AspectJ 1.9.19 supports https://openjdk.java.net/projects/jdk/19/[Java 19] and its final, preview and incubator
+features, such as:
+
+* Record patterns (preview)
+* Virtual threads (preview)
+* Pattern matching for `switch` (preview 3)
+* Structured concurrency (incubator)
+
+Please note that the upstream Eclipse Java Compiler (ECJ) which the AspectJ Compiler (AJC) is a fork of still has some
+open issues concerning Java 19 preview feature support, see the list in
+https://github.com/eclipse/org.aspectj/issues/184#issuecomment-1272254940[this comment]. AJC therefore inherits the same
+problems for the specific cases described in the linked issues.
+
+=== Improvements
+
+* Improve condy (constant dynamic) support. Together with some custom compilation or weaving options, this helps to
+  avoid a problem when using JaCoCo together with AspectJ, see
+  https://github.com/eclipse/org.aspectj/issues/170#issuecomment-1214163297[this comment in #170] for more details.
+
+=== Code examples
+
+You can find some sample code in the AspectJ test suite under the respective AspectJ version in which the features were
+first supported (possibly as JVM preview features):
+
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features198/java17[Pattern matching for switch (preview 1)]
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features199/java18[Pattern matching for switch (preview 2)]
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features1919/java19[Pattern matching for switch (preview 3),
+  record patterns (preview 1)]
+* Please note that presently there is no specific sample code for virtual threads and structured concurrency in the
+  AspectJ code base, because these are just new APIs, no Java language features. You can find sample code for these
+  concurrency features elsewhere, e.g. in the corresponding JEPs. In AspectJ, they should just work transparently like
+  any other Java API.
+
+=== Other changes and bug fixes
+
+* Fix (or rather work around) an old bug occurring when compiling or weaving code using ITD to declare annotations with
+  `SOURCE` retention on types, methods, constructors or fields. While declaring such annotations does not make sense to
+  begin with, at least the AspectJ weaver or compiler should handle the situation gracefully, which now it does by
+  simply ignoring errors caused by it. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=366085[Bugzilla #366085] and
+  https://github.com/eclipse/org.aspectj/pull/196[pull request #196]. Better than this workaround would be for the
+  compiler or weaver to actually print a warning when meeting source level annotations in declare statements. Hence,
+  follow-up issue https://github.com/eclipse/org.aspectj/issues/201[#201] was created.
+* Remove legacy AspectJ Browser code and documentation.
+* Thanks to Andrey Turbanov for several clean code contributions.
+
+=== AspectJ usage hints
+
+==== AspectJ compiler build system requirements
+
+Since 1.9.8, the AspectJ compiler `ajc` (contained in the `aspectjtools` library) no longer works on JDKs 8 to 10. The
+minimum compile-time requirement is now JDK 11 due to upstream changes in the Eclipse Java Compiler (subset of JDT
+Core), which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling
+plain Java code or using plain Java ITD constructs which do not require the AspectJ runtime `aspectjrt`, but the
+compiler itself needs JDK 11+. Just like in previous AspectJ versions, both the runtime `aspectjrt` and the load-time
+weaver `aspectjweaver` still only require JRE 8+.
+
+==== Use LTW on Java 16+
+
+Please note that if you want to use load-time weaving on Java 16+, the weaving agent collides with
+https://openjdk.java.net/jeps/396[JEP 396 (Strongly Encapsulate JDK Internals by Default)]. Therefore, you need to set
+the JVM parameter `--add-opens java.base/java.lang=ALL-UNNAMED` in order to enable aspect weaving. This is due to the
+fact that the weaver uses internal APIs for which we have not found an adequate replacement yet when defining classes
+in different classloaders.
+
+==== Compile with Java preview features
+
+For features marked as preview on a given JDK, you need to compile with `ajc --enable-preview` and run with
+`java --enable-preview` on that JDK.
+
+Please note, that you cannot run code compiled with preview features on any other JDK than the one used for compilation.
+For example, records compiled with preview on JDK 15 cannot be used on JDK 16 without recompilation. This is a JVM
+limitation unrelated to AspectJ. Also, e.g. sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16. You still
+need to recompile, no matter what.
diff --git a/docs/dist/doc/README-1.9.2.adoc b/docs/dist/doc/README-1.9.2.adoc
new file mode 100644
index 000000000..94da278bf
--- /dev/null
+++ b/docs/dist/doc/README-1.9.2.adoc
@@ -0,0 +1,13 @@
+== AspectJ 1.9.2
+
+_© Copyright 2018 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.9.2 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.2[here]
+
+=== Java 11 support
+
+AspectJ now supports Java11. It has been updated to a more recent JDT
+compiler that supports Java 11 (JDTCore #6373b82afa49b).
+
+Available: 1.9.2 available Oct-2018
diff --git a/docs/dist/doc/README-1.9.20.adoc b/docs/dist/doc/README-1.9.20.adoc
new file mode 100644
index 000000000..51b9033e9
--- /dev/null
+++ b/docs/dist/doc/README-1.9.20.adoc
@@ -0,0 +1,109 @@
+== AspectJ 1.9.20.1
+
+_© Copyright 2023 Contributors. All rights reserved._
+
+_Release info: 1.9.20.1 available 04-Sep-2023_
+
+This is a bugfix release for 1.9.20, fixing two problems:
+
+* https://github.com/eclipse-aspectj/aspectj/issues/257[Regression bug 257] introduced in 1.9.20 would match negated
+  type patterns like `!void` or `!String[]` incorrectly.
+* https://github.com/spring-projects/spring-framework/issues/27761[Spring issue 27761] describes a problem where
+  AspectJ, when used by Spring AOP, in rare cases falsely considered bridge methods for overridden generic methods for
+  matching, leading to falsely negative matching results. See also
+  https://github.com/eclipse-aspectj/aspectj/issues/256[AspectJ tracker issue 256]).
+
+The list of issues addressed for 1.9.20.1 can be found
+https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.20.1[here].
+
+== AspectJ 1.9.20
+
+_© Copyright 2023 Contributors. All rights reserved._
+
+_Release info: 1.9.20 available 16-Aug-2023_
+
+Please note that Bugzilla for issue management is deprecated and new issues should be filed as
+https://github.com/eclipse/org.aspectj/issues/new[GitHub issues]. The list of issues addressed for 1.9.20 can be found
+here:
+
+* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.20[GitHub 1.9.20]
+* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.20.1[GitHub 1.9.20.1]
+* https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.20[Bugzilla 1.9.20]
+
+=== New features
+
+AspectJ 1.9.20 supports https://openjdk.java.net/projects/jdk/20/[Java 20] and its final, preview and incubator
+features, such as:
+
+* Record patterns (preview)
+* Virtual threads (preview)
+* Pattern matching for `switch` (preview 3)
+* Structured concurrency (incubator)
+
+Please note, that the upstream Eclipse Java Compiler (ECJ), which the AspectJ Compiler (AJC) is a fork of, still has
+some open issues concerning Java 20 preview feature support, see the list in
+https://github.com/eclipse/org.aspectj/issues/184#issuecomment-1272254940[this comment]. AJC therefore inherits the same
+problems for the specific cases described in the linked issues.
+
+=== Improvements
+
+* Since Java 9 and the introduction of the Java Module System, the upstream Eclipse Java Compiler (ECJ) and Eclipse Java
+  Development Tools (JDT) had gone through some internal changes, enabling both the compiler and the IDE to handle new
+  Java language features. In AspectJ, some of those internal changes have not been properly upgraded for quite a while,
+  but this is now fixed. However, it might *require you to recompile your aspects and projects/classes using them.*
+  Otherwise, you might get problems in Eclipse IDE or under certain circumstances even when running newly compiled
+  aspects in older AspectJ versions and vice versa. You are on the safe side if you simply rebuild your projects. We are
+  sorry for the inconvenience, but we have to follow upstream ECJ and JDT changes.
+* Along with fixing https://github.com/eclipse-aspectj/aspectj/issues/24[GitHub bug 24], the syntax for array type
+  matching has been improved considerably. You can find some examples
+  https://github.com/eclipse-aspectj/aspectj/tree/master/tests/bugs1920/github_24[here].
+
+=== Code examples
+
+You can find some sample code in the AspectJ test suite under the respective AspectJ version in which the features were
+first supported (possibly as JVM preview features):
+
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features198/java17[Pattern matching for switch (preview 1)]
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features199/java18[Pattern matching for switch (preview 2)]
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features1919/java19[Pattern matching for switch (preview 3),
+  record patterns (preview 1)]
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features1920/java20[Pattern matching for switch (preview 4),
+  record patterns (preview 2)]
+* Please note that presently there is no specific sample code for virtual threads and structured concurrency in the
+  AspectJ code base, because these are just new APIs, no Java language features. You can find sample code for these
+  concurrency features elsewhere, e.g. in the corresponding JEPs. In AspectJ, they should just work transparently like
+  any other Java API.
+
+=== Other changes and bug fixes
+
+* About a dozen bugs have been fixed, some of them quite old. See "list of issues addressed" further above and follow
+  the link to GitHub to find out if your issue is among them.
+
+=== AspectJ usage hints
+
+==== AspectJ compiler build system requirements
+
+Since 1.9.8, the AspectJ compiler `ajc` (contained in the `aspectjtools` library) no longer works on JDKs 8 to 10. The
+minimum compile-time requirement is now JDK 11 due to upstream changes in the Eclipse Java Compiler (subset of JDT
+Core), which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling
+plain Java code or using plain Java ITD constructs which do not require the AspectJ runtime `aspectjrt`, but the
+compiler itself needs JDK 11+. Just like in previous AspectJ versions, both the runtime `aspectjrt` and the load-time
+weaver `aspectjweaver` still only require JRE 8+.
+
+==== Use LTW on Java 16+
+
+Please note that if you want to use load-time weaving on Java 16+, the weaving agent collides with
+https://openjdk.java.net/jeps/396[JEP 396 (Strongly Encapsulate JDK Internals by Default)]. Therefore, you need to set
+the JVM parameter `--add-opens java.base/java.lang=ALL-UNNAMED` in order to enable aspect weaving. This is due to the
+fact that the weaver uses internal APIs for which we have not found an adequate replacement yet when defining classes
+in different classloaders.
+
+==== Compile with Java preview features
+
+For features marked as preview on a given JDK, you need to compile with `ajc --enable-preview` and run with
+`java --enable-preview` on that JDK.
+
+Please note, that you cannot run code compiled with preview features on any other JDK than the one used for compilation.
+For example, records compiled with preview on JDK 15 cannot be used on JDK 16 without recompilation. This is a JVM
+limitation unrelated to AspectJ. Also, e.g. sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16. You still
+need to recompile, no matter what.
diff --git a/docs/dist/doc/README-1.9.21.adoc b/docs/dist/doc/README-1.9.21.adoc
new file mode 100644
index 000000000..d205ed36d
--- /dev/null
+++ b/docs/dist/doc/README-1.9.21.adoc
@@ -0,0 +1,81 @@
+== AspectJ 1.9.21
+
+_© Copyright 2023 Contributors. All rights reserved._
+
+_Release info: 1.9.21 available 11-Dec-2023_
+
+Please note that Bugzilla for issue management is deprecated and new issues should be filed as
+https://github.com/eclipse/org.aspectj/issues/new[GitHub issues]. The list of issues addressed for 1.9.21 can be found
+here:
+
+* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.21[GitHub 1.9.21]
+* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.21.1[GitHub 1.9.21.1]
+* https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.21[Bugzilla 1.9.21]
+
+=== New features
+
+AspectJ 1.9.21 supports https://openjdk.java.net/projects/jdk/21/[Java 21], its final features and a subset of preview
+features, such as:
+
+* Record patterns
+* Pattern matching for switch
+* Virtual threads
+* Sequenced collections
+* Structured concurrency (preview)
+* String templates (preview)
+* Instance main methods (preview)
+
+Unfortunately, even after holding back the AspectJ release for 3 months after JDK 21 general availability, waiting for
+Eclipse JDT Core and the Eclipse Java Compiler (ECJ) to catch up with Java 21 language features, even with Java 21
+officially supported in Eclipse 2023-12, some preview features are still unimplemented in ECJ:
+
+* Unnamed classes (preview)
+* Unnamed patterns and variables (preview)
+
+As soon as these preview features are part of the upstream ECJ we depend on, we hope to publish another AspectJ release
+to support them in the AspectJ Compiler (AJC), too.
+
+=== Improvements
+
+* In https://github.com/eclipse-aspectj/aspectj/issues/266[GitHub issue 266], exception cause reporting has been
+  improved in `ExtensibleURLClassLoader`. Thanks to Andy Russell (@euclio) for his contribution.
+
+=== Other changes and bug fixes
+
+* No major bug fixes
+
+=== AspectJ usage hints
+
+==== AspectJ compiler build system requirements
+
+Since 1.9.21, the AspectJ compiler `ajc` (contained in the `aspectjtools` library) no longer works on JDKs 11 to 16. The
+minimum compile-time requirement is now JDK 17 due to upstream changes in the Eclipse Java Compiler (subset of JDT
+Core), which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling
+plain Java code or using plain Java ITD constructs which do not require the AspectJ runtime `aspectjrt`, but the
+compiler itself needs JDK 17+. Just like in previous AspectJ versions, both the runtime `aspectjrt` and the load-time
+weaver `aspectjweaver` still only require JRE 8+.
+
+Please note: If you run `ajc` on JDKs 11-16, you will probably see an error like `java.lang.NoSuchFieldError:
+RELEASE_17`, and an _ajcore.*.txt_ dump file will be created, while running it on even older JDKs will rather yield an
+`UnsupportedClassVersionError`. See https://github.com/eclipse-aspectj/aspectj/issues/269[GitHub issue 269] for more
+details.
+
+History: Since 1.9.8, the AspectJ compiler ajc needed JDK 11+, before then JDK 8+.
+
+==== Use LTW on Java 16+
+
+Please note that if you want to use load-time weaving on Java 16+, the weaving agent collides with
+https://openjdk.java.net/jeps/396[JEP 396 (Strongly Encapsulate JDK Internals by Default)] and related subsequent
+JEPs. Therefore, you need to set the JVM parameter `--add-opens java.base/java.lang=ALL-UNNAMED` in order to enable
+aspect weaving. This is due to the fact that the weaver uses internal APIs for which we have not found an adequate
+replacement yet when defining classes in different classloaders.
+
+==== Compile with Java preview features
+
+For features marked as preview on a given JDK, you need to compile with `ajc --enable-preview` and run with
+`java --enable-preview` on that JDK.
+
+Please note, that you cannot run code compiled with preview features on any other JDK than the one used for compilation.
+For example, records compiled with preview on JDK 15 cannot be used on JDK 16 without recompilation. This is a JVM
+limitation unrelated to AspectJ. Also, e.g. sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16. You still
+need to recompile, no matter what.
diff --git a/docs/dist/doc/README-1.9.3.adoc b/docs/dist/doc/README-1.9.3.adoc
new file mode 100644
index 000000000..aa130dbc5
--- /dev/null
+++ b/docs/dist/doc/README-1.9.3.adoc
@@ -0,0 +1,75 @@
+== AspectJ 1.9.3
+
+_© Copyright 2018 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.9.3 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.3[here]
+
+_Release info: 1.9.3 available 4-Apr-2019_
+
+AspectJ 1.9.3 supports Java12. Java12 introduces the new switch
+expression syntax, but you must activate support for that via an
+`--enable-preview` flag when using the compiler and attempting to run the
+resultant classes: Here is `Switch3.java`:
+
+[source, java]
+....
+public class Switch3 {
+  public static void main(String[] argv) {
+    System.out.println(one(Color.R));
+    System.out.println(one(Color.G));
+    System.out.println(one(Color.B));
+    System.out.println(one(Color.Y));
+  }
+
+  public static int one(Color color) {
+    int result = switch(color) {
+      case R -> foo(0);
+      case G -> foo(1);
+      case B -> foo(2);
+      default -> foo(3);
+    };
+    return result;
+  }
+
+  public static final int foo(int i) {
+    return i+1;
+  }
+}
+
+enum Color {
+  R, G, B, Y;
+}
+
+aspect X {
+  int around(): call(* foo(..)) {
+    return proceed()*3;
+  }
+}
+....
+
+Compile it with:
+
+[source, text]
+....
+$ ajc --enable-preview -showWeaveInfo -12 Switch3.java
+
+Join point 'method-call(int Switch3.foo(int))' in Type 'Switch3' (Switch3.java:12) advised by around advice from 'X' (Switch3.java:30)
+
+Join point 'method-call(int Switch3.foo(int))' in Type 'Switch3' (Switch3.java:13) advised by around advice from 'X' (Switch3.java:30)
+
+Join point 'method-call(int Switch3.foo(int))' in Type 'Switch3' (Switch3.java:14) advised by around advice from 'X' (Switch3.java:30)
+
+Join point 'method-call(int Switch3.foo(int))' in Type 'Switch3' (Switch3.java:15) advised by around advice from 'X' (Switch3.java:30)
+....
+
+Now run it:
+
+[source, text]
+....
+$ java --enable-preview Switch3
+3
+6
+9
+12
+....
diff --git a/docs/dist/doc/README-1.9.4.adoc b/docs/dist/doc/README-1.9.4.adoc
new file mode 100644
index 000000000..72d6ca404
--- /dev/null
+++ b/docs/dist/doc/README-1.9.4.adoc
@@ -0,0 +1,25 @@
+== AspectJ 1.9.4
+
+_© Copyright 2019 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.9.4 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.4[here]
+
+_Release info: 1.9.4 available 10-May-2019_
+
+AspectJ 1.9.4 has a couple of important fixes in it:
+
+* Due to the new maven build process being used to build release
+artifacts for the first time, there were errors in the _aspectjweaver_ JAR
+that affected the ability to use it on the command line as an agent,
+this is now fixed.
+
+* A number of users were noticing a `ClassCastException` problem, which I
+believe was due to trying to run AspectJ on one level of the JDK whilst
+targeting another. This can happen quite easily in Eclipse if running
+your Eclipse on Java 8 but developing projects targeting Java 11. The
+class cast is because Java8 couldn't understand the packaging of system
+classes post Java9 and so couldn't find `java.lang.Object`. This has now
+all been tidied up and should work much better. More details in
+https://bugs.eclipse.org/bugs/show_bug.cgi?id=546807[546807], thanks to
+Denys Khanzhyiev for some tips on getting to the right solution.
diff --git a/docs/dist/doc/README-1.9.5.adoc b/docs/dist/doc/README-1.9.5.adoc
new file mode 100644
index 000000000..662c561bc
--- /dev/null
+++ b/docs/dist/doc/README-1.9.5.adoc
@@ -0,0 +1,54 @@
+== AspectJ 1.9.5
+
+_© Copyright 2019 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.9.5 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.5[here]
+
+_Release info: 1.9.5 available 28-Nov-2019_
+
+AspectJ 1.9.5 supports Java13. Java13 introduces text blocks, but you
+must activate support for that via an `--enable-preview` flag when using
+the compiler and attempting to run the resultant classes: Here is
+`Code.java`:
+
+[source, java]
+....
+public class Code {
+  public static void main(String[] argv) {}
+
+  static aspect X {
+    before(): execution(* Code.main(..)) {
+    System.out.println(
+"""
+This
+is
+on
+multiple
+lines
+"""
+);
+    }
+  }
+
+}
+....
+
+Compile it with:
+
+[source, text]
+....
+$ ajc --enable-preview -13 Code.java
+....
+
+Now run it:
+
+[source, text]
+....
+$ java --enable-preview Code
+This
+is
+on
+multiple
+lines
+....
diff --git a/docs/dist/doc/README-1.9.6.adoc b/docs/dist/doc/README-1.9.6.adoc
new file mode 100644
index 000000000..0ecbc8967
--- /dev/null
+++ b/docs/dist/doc/README-1.9.6.adoc
@@ -0,0 +1,49 @@
+== AspectJ 1.9.6
+
+_© Copyright 2020 Contributors. All rights reserved._
+
+The full list of resolved issues in 1.9.6 is available
+https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.6[here]
+
+_Release info: 1.9.6 available 22-Jul-2020_
+
+AspectJ 1.9.6 supports Java14. Java14 introduces records, but you must
+activate support for that via an `--enable-preview` flag when using the
+compiler and attempting to run the resultant classes: Here is `Code.java`:
+
+[source, java]
+....
+public record Person(String firstName, String lastName, int age) {}
+
+public class UsingPersonRecord {
+  public static void main(String[] argv) {
+    Person p = new Person("A","B",99);
+    System.out.println(p);
+    System.out.println(p.firstName());
+  }
+}
+
+public aspect TraceRecordComponents {
+  before(): execution(public * *()) {
+    System.out.println(thisJoinPointStaticPart);
+  }
+}
+....
+
+Compile it with:
+
+[source, text]
+....
+$ ajc --enable-preview -14 Person.java UsingPersonRecord.java TraceRecordComponents.java
+....
+
+Now run it:
+
+[source, text]
+....
+$ java --enable-preview UsingPersonRecord
+execution(String Person.toString())
+Person[firstName=A, lastName=B, age=99]
+execution(String Person.firstName())
+A
+....
diff --git a/docs/dist/doc/README-1.9.7.adoc b/docs/dist/doc/README-1.9.7.adoc
new file mode 100644
index 000000000..1f96cd5bb
--- /dev/null
+++ b/docs/dist/doc/README-1.9.7.adoc
@@ -0,0 +1,109 @@
+== AspectJ 1.9.7
+
+_© Copyright 2021 Contributors. All rights reserved._
+
+_Release info: 1.9.7 available 24-Jun-2021_
+
+AspectJ (binaries, source code, documentation) is now distributed under
+the https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.txt[Eclipse
+Public License v 2.0].
+
+Please note, that going forward Bugzilla for issue management is
+deprecated, and new issues should be filed as
+https://github.com/eclipse/org.aspectj/issues/new[GitHub issues]. The
+list of issues addressed for 1.9.7 can be found
+https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.7[here
+for Bugzilla] and
+https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.7[here
+for GitHub issues].
+
+=== New features
+
+AspectJ 1.9.7 supports https://openjdk.java.net/projects/jdk/15/[Java
+15] & https://openjdk.java.net/projects/jdk/16/[Java 16] and their
+respective final and review features:
+
+* text blocks (final 15)
+* records (preview 15, final 16)
+* instanceof pattern matching (preview 15, final 16)
+* hidden classes (final 15)
+* sealed classes (preview 15, preview 16)
+
+For features marked as preview on a given JDK, you need to compile with
+`ajc --enable-preview` and run with `java --enable-preview on` that JDK.
+
+Please note, that you cannot run code compiled with preview features on
+any other JDK than the one used for compilation. For example, records
+compiled with preview on JDK 15 cannot be used on JDK 16 without
+recompilation. This is a JVM limitation unrelated to AspectJ. Also, e.g.
+sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16. You
+still need to recompile, no matter what.
+
+You can find some sample code in the AspectJ test suite under the
+respective AspectJ version in which the features were first supported
+(possibly as JVM preview features):
+
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features195/textblock[AspectJ
+1.9.5: text blocks]
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features196/java14[AspectJ
+1.9.6: records, instanceof patterns]
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features197/java15[AspectJ
+1.9.7: hidden classes, sealed classes]
+
+=== Using LTW on Java 16+
+
+Please note that if you want to use load-time weaving on Java 16+, the
+weaving agent collides with https://openjdk.java.net/jeps/396[JEP 396
+(Strongly Encapsulate JDK Internals by Default)]. Therefore, you need to
+set the JVM parameter `--add-opens java.base/java.lang=ALL-UNNAMED` in
+order to enable aspect weaving. This is due to the fact that the weaver
+uses internal APIs for which we have not found an adequate replacement
+yet when defining classes in different classloaders.
+
+=== Organisational and internal changes
+
+For AspectJ 1.9.7, we implemented a lot of internal changes concerning
+the build and release process, most of which are not visible in the
+product itself but will help us to more easily maintain and release the
+product in the future and more easily on-boarding new developers or
+contributors. For example:
+
+* The main repository has been moved to
+https://github.com/eclipse/org.aspectj[GitHub], i.e. you can open bug
+reports, feature requests and pull requests there now.
+* The Maven build has been improved, i.e. it is now easier to build and
+contribute to the product. Developers can just import the Maven project
+and no longer depend on Eclipse to build and test AspectJ, but can e.g.
+also use IntelliJ IDEA.
+* Continuous integration builds now run on GitHub for different JDK
+versions, also for pull requests. I.e. both maintainers and contributors
+get to know if their changes break any tests.
+* We can build releases and deploy them directly to Sonatype OSSRH
+(snapshots) or Maven Central (releases) with Maven now, i.e. it should
+be much easier in the future to publish development versions in order to
+enable users to re-test fixed bugs or try new features.
+* All tests are portable now, i.e. they correctly run on Windows, too.
+This enables developers and contributors to make a choice if they want
+to work on Linux or on Windows.
+
+=== Other changes and bug fixes
+
+* Remove legacy JRockit support.
+* Support Windows 10 and Windows Server 2016/2019 in installer. Those
+versions were not detected until now, which led to bogus Windows batch
+files forwarding only 9 AJC parameters to the Java process via `%1 %2 %3
+%4 %5 %6 %7 %8 %9` instead of `%*`.
+* AJdoc (AspectJ's javadoc generator add-on for aspects) now supports
+the JDK 16 javadoc generator.
+* Fix `serialVersionUID` initialization for Java 9+
+* AJC (AspectJ Compiler) usage texts sometimes used to be printed twice
+and they were printed too often, e.g. on top of every compile error.
+This has been fixed. Furthermore, the partly outdated usage text is now
+basically the same as ECJ (Eclipse Java Compiler), which AJC is a fork
+of, plus AspectJ-specific additions which are added during runtime.
+* Source and javadoc JARs distributed together with the AspectJ
+artifacts on Maven Central are now more accurate and more complete with
+regard to what is included (ASM, JDT Core) and how package names have
+been relocated.
+* Fix sample code formatting issues (indentation) throughout the
+documentation.
diff --git a/docs/dist/doc/README-1.9.8.adoc b/docs/dist/doc/README-1.9.8.adoc
new file mode 100644
index 000000000..29b04ef7c
--- /dev/null
+++ b/docs/dist/doc/README-1.9.8.adoc
@@ -0,0 +1,86 @@
+== AspectJ 1.9.8
+
+_© Copyright 2022 Contributors. All rights reserved._
+
+_Release info: 1.9.8 available 11-Feb-2022_
+
+Please note, that Bugzilla for issue management is deprecated, and new issues should be filed as
+https://github.com/eclipse/org.aspectj/issues/new[GitHub issues]. The list of issues addressed for 1.9.8 can be found
+https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.8[here for Bugzilla] and
+https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.8[here for GitHub issues].
+
+=== New features
+
+AspectJ 1.9.8 supports https://openjdk.java.net/projects/jdk/17/[Java 17] and its final and review features, such as:
+
+* Sealed classes (final in Java 17, previews in Java 15, 16 and AspectJ 1.9.7)
+* Pattern matching for `switch`
+
+=== Improvements
+
+The `--release N` compiler option for correct cross-compilation to previous JDK bytecode + API versions is now supported
+by AJC. Previously, the option existed (inherited by ECJ) but did not work correctly.
+
+The following new properties can improve performance, e.g. Spring start-up time:
+
+* `org.aspectj.apache.bcel.useSingleRepositoryInstance`
+* `org.aspectj.apache.bcel.useUnavailableClassesCache`
+* `org.aspectj.apache.bcel.ignoreCacheClearRequests`
+
+For now, they all default to `false` for backward compatibility. This might change in a future Aspect release, if user
+feedback is positive and no negative side effects are found. Please try using them as much as you can and report back
+questions (to the AspectJ users mailing list) or problems (as a GitHub issue), if any. Thanks to Stefan Starke for his
+contribution. See also https://github.com/eclipse/org.aspectj/pull/37[PR #37].
+
+=== Code examples
+
+You can find some sample code in the AspectJ test suite under the respective AspectJ version in which the features were
+first supported (possibly as JVM preview features):
+
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features198/compiler_release[Cross-compilation to legacy JDK]:
+  An example class which only works correctly on JDK 8 when compiled with `--release 8` due to API changes in
+  the JDK. Simply `-source 8 -target 8` would not be enough in this case.
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features198/java17[Pattern matching for `switch`]
+
+=== Other changes and bug fixes
+
+* The AspectJ compiler `ajc` (contained in the `aspectjtools` library) no longer works on JDKs 8 to 10. The minimum
+  compile-time requirement is now JDK 11 due to upstream changes in the Eclipse Java Compiler (subset of JDT Core),
+  which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling plain
+  Java code or using plain Java ITD constructs which do not require the AspectJ runtime `aspectjrt`, but the compiler
+  itself needs JDK 11+. Just like in previous AspectJ versions, both the runtime `aspectjrt` and the load-time weaver
+  `aspectjweaver` still only require JRE 8+.
+* Document build profiles and properties in _docs/developer/BUILD.md_
+* Add a guide for setting up an AspectJ development environment in _docs/developer/IDE.md_
+* Fix https://github.com/eclipse/org.aspectj/issues/105[issue #105]: Compilation fails when using an aspect library via
+  `-aspectpath` in combination with introducing an annotation via ITD. This was broken since version 1.9.5 and fixed in
+  1.9.8.RC3.
+* Fix https://github.com/eclipse/org.aspectj/issues/68[issue #68]: Correctly process class files containing
+  https://openjdk.java.net/jeps/309[dynamic class-file constants (JEP 309)], which were introduced in Java 11 and broken
+  in AspectJ ever since their introduction in 1.9.2. Java itself currently does not use "condy" and neither do other
+  widespread JVM languages. Byte code engineering libraries like ASM or Byte Buddy and some instrumentation tools like
+  JaCoCo can however produce condy code. Therefore, in order to create a regression test, we actually had to
+  https://github.com/eclipse/org.aspectj/blob/de63b63d/tests/bugs198/github_68/Generator.java#L50-L61[craft a condy
+  class with ASM].
+* Thanks to Andrey Turbanov for several clean code contributions and to Dmitry Mikhaylov for fixing a potential
+  concurrency problem.
+
+=== AspectJ usage hints
+
+==== Use LTW on Java 16+
+
+Please note that if you want to use load-time weaving on Java 16+, the weaving agent collides with
+https://openjdk.java.net/jeps/396[JEP 396 (Strongly Encapsulate JDK Internals by Default)]. Therefore, you need to set
+the JVM parameter `--add-opens java.base/java.lang=ALL-UNNAMED` in order to enable aspect weaving. This is due to the
+fact that the weaver uses internal APIs for which we have not found an adequate replacement yet when defining classes
+in different classloaders.
+
+==== Compile with Java preview features
+
+For features marked as preview on a given JDK, you need to compile with `ajc --enable-preview` and run with
+`java --enable-preview` on that JDK.
+
+Please note, that you cannot run code compiled with preview features on any other JDK than the one used for compilation.
+For example, records compiled with preview on JDK 15 cannot be used on JDK 16 without recompilation. This is a JVM
+limitation unrelated to AspectJ. Also, e.g. sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16. You still
+need to recompile, no matter what.
diff --git a/docs/dist/doc/README-1.9.9.adoc b/docs/dist/doc/README-1.9.9.adoc
new file mode 100644
index 000000000..900f70b89
--- /dev/null
+++ b/docs/dist/doc/README-1.9.9.adoc
@@ -0,0 +1,94 @@
+== AspectJ 1.9.9.1
+
+_© Copyright 2022 Contributors. All rights reserved._
+
+_Release info: 1.9.9.1 available 31-Mar-2022_
+
+Bugfix release for some compiler options related to the Java Platform Module System (JPMS) which were not working, most
+importantly `--add-modules`, `--add-exports` and `--add-reads`. See
+https://github.com/eclipse/org.aspectj/issues/145[issue #145].
+
+This probably was broken for a long time. AspectJ still is not boasting extensive JPMS support or test coverage, but
+this improvement seems substantial enough to justify a minor release, instead of keeping users waiting for the next
+regular release.
+
+== AspectJ 1.9.9
+
+_© Copyright 2022 Contributors. All rights reserved._
+
+_Release info: 1.9.9 available 24-Mar-2022_
+
+Please note that Bugzilla for issue management is deprecated and new issues should be filed as
+https://github.com/eclipse/org.aspectj/issues/new[GitHub issues]. The list of issues addressed for 1.9.9 can be found
+here:
+
+* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.9[GitHub 1.9.9]
+* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.9.1[GitHub 1.9.9.1]
+* https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.9[Bugzilla 1.9.9]
+
+=== New features
+
+AspectJ 1.9.9 supports https://openjdk.java.net/projects/jdk/18/[Java 18] and its final and preview features, such as:
+
+* Pattern matching for `switch` (preview 2)
+
+=== Improvements
+
+In annotation style aspects, asynchronous `proceed()` calls in `@Around` advice now works in threads created from within
+the advice. Previously, this was only working in native syntax aspects. There is still a limitation with regard to
+asynchronous proceed, if you do not create the thread in the advice but want to use e.g. an `ExecutorService` with its
+own thread pool. This still is not working in annotation style aspects, only in native syntax ones.
+
+See https://github.com/eclipse/org.aspectj/issues/128[issue #128] and
+https://github.com/eclipse/org.aspectj/pull/132[pull request #132] for more details.
+
+=== Code examples
+
+You can find some sample code in the AspectJ test suite under the respective AspectJ version in which the features were
+first supported (possibly as JVM preview features):
+
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features198/java17[Pattern matching for switch, preview 1]
+* https://github.com/eclipse/org.aspectj/tree/master/tests/features199/java18[Pattern matching for switch, preview 2]
+* https://github.com/eclipse/org.aspectj/tree/master/tests/bugs199/github_128[Asynchronous proceed in native vs.
+  annotation style syntax]
+
+=== Other changes and bug fixes
+
+* Fix a bug which led to ``NullPointerException``s, if too many JAR archives were on the classpath. Too many here means
+  the value of system property `org.aspectj.weaver.openarchives` (1,000 by default). The AspectJ compiler is meant to
+  close archives upon cache exhaustion and then re-open them, if it needs them again later. Re-opening was broken, but
+  now the compiler works reliably even for cache sizes as small as 20. See
+  https://github.com/eclipse/org.aspectj/issues/125[issue #125].
+* Improvements for `if()` pointcuts in annotation syntax, see issues
+  https://github.com/eclipse/org.aspectj/issues/115[#115], https://github.com/eclipse/org.aspectj/issues/120[#120],
+  https://github.com/eclipse/org.aspectj/issues/122[#122].
+* Thanks to Andrey Turbanov for several clean code contributions.
+
+=== AspectJ usage hints
+
+==== AspectJ compiler build system requirements
+
+Since 1.9.8, the AspectJ compiler `ajc` (contained in the `aspectjtools` library) no longer works on JDKs 8 to 10. The
+minimum compile-time requirement is now JDK 11 due to upstream changes in the Eclipse Java Compiler (subset of JDT
+Core), which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling
+plain Java code or using plain Java ITD constructs which do not require the AspectJ runtime `aspectjrt`, but the
+compiler itself needs JDK 11+. Just like in previous AspectJ versions, both the runtime `aspectjrt` and the load-time
+weaver `aspectjweaver` still only require JRE 8+.
+
+==== Use LTW on Java 16+
+
+Please note that if you want to use load-time weaving on Java 16+, the weaving agent collides with
+https://openjdk.java.net/jeps/396[JEP 396 (Strongly Encapsulate JDK Internals by Default)]. Therefore, you need to set
+the JVM parameter `--add-opens java.base/java.lang=ALL-UNNAMED` in order to enable aspect weaving. This is due to the
+fact that the weaver uses internal APIs for which we have not found an adequate replacement yet when defining classes
+in different classloaders.
+
+==== Compile with Java preview features
+
+For features marked as preview on a given JDK, you need to compile with `ajc --enable-preview` and run with
+`java --enable-preview` on that JDK.
+
+Please note, that you cannot run code compiled with preview features on any other JDK than the one used for compilation.
+For example, records compiled with preview on JDK 15 cannot be used on JDK 16 without recompilation. This is a JVM
+limitation unrelated to AspectJ. Also, e.g. sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16. You still
+need to recompile, no matter what.
diff --git a/docs/dist/doc/README-11.adoc b/docs/dist/doc/README-11.adoc
deleted file mode 100644
index d846cff81..000000000
--- a/docs/dist/doc/README-11.adoc
+++ /dev/null
@@ -1,1381 +0,0 @@
-[[readme-1_1]]
-== AspectJ 1.1
-
-_© Copyright 2002 Palo Alto Research Center, Incorporated, 2003
-Contributors. All rights reserved._
-
-This is the initial release of AspectJ 1.1. It includes a small number
-of new language features as well as major improvements to the
-functionality of the tools.
-
-This document describes the differences between AspectJ versions 1.1 and
-1.0.6. Users new to AspectJ need only read the
-link:progguide/index.html[AspectJ Programming Guide] since it describes
-the 1.1 language. Users familiar with AspectJ 1.0 may find this document
-a quicker way to learn what changed in the language and tools, and
-should use it as a guide for porting programs from 1.0 to 1.1.
-
-This document first summarizes changes from the 1.0 release in
-
-* xref:#language[the language],
-* xref:#compiler[the compiler],
-* xref:#tools[the support tools],
-* xref:#runtime[the runtime],
-* xref:#devenv[the development environment support],
-* xref:#sources[the sources], and
-* xref:#distribution[the distribution],
-
-then xref:#details[details] some of the language and compiler changes,
-and finally points readers to the bug database for any
-xref:#knownLimitations[known limitations].
-
-'''''
-
-[[language]]
-=== The Language
-
-AspectJ 1.1 is a slightly different language than AspectJ 1.0. In all
-but a few cases, programs written in AspectJ 1.0 should compile
-correctly in AspectJ 1.1. In many cases, there are new or preferred
-forms in AspectJ 1.1. However, some AspectJ 1.0 features have changed in
-1.1, so some 1.0 programs will not compile or will run differently in
-1.1. The corresponding features are marked below as compile-time or
-run-time incompatible (_CTI_ or _RTI_, respectively). When the language
-change involves a move in the static shadow effective at run-time but
-also apparent at compile-time (e.g., in declare error or warning
-statements), it is marked _CRTI_. Programs using run-time incompatible
-forms should be verified that they are behaving as expected in 1.1.
-
-Most changes to the language are additions to expressibility requested
-by our users:
-
-* xref:#THROWS_PATTERN[Matching based on throws]: You can now make finer
-discriminations between methods based on declared exceptions.
-* xref:#NEW_PCDS[New kinded pointcut designators]: Now every kind of
-join point has a corresponding kinded pointcut designator.
-
-Some are have different behavior in edge cases but offer improved power
-and clarity:
-
-* xref:#ASPECT_PRECEDENCE[New aspect precedence form]: AspectJ 1.1 has a
-new declare form, `declare     precedence`, that replaces the
-"dominates" clause on aspects. (_CTI_)
-* The order of xref:#SUPER_IFACE_INITS[initialization join points for
-super-interfaces] has been clarified. (_RTI_)
-
-But in order to support weaving into bytecode effectively, several
-incompatible changes had to be made to the language:
-
-* A class's default constructor may
-xref:#DEFAULT_CONSTRUCTOR_CONFLICT[conflict] with an inter-type
-constructor. (_CTI_)
-* xref:#NO_CALLEE_SIDE_CALL[No callee-side call join points]: The
-AspectJ 1.1 compiler does not expose call join points unless it is given
-the calling code. (_CRTI_)
-* xref:#SINGLE_INTERCLASS_TARGET[One target for intertype declarations].
-(_CTI_)
-* xref:#UNAVAILABLE_JOIN_POINTS[No initializer execution join points].
-(_RTI_)
-* xref:#AFTER_HANDLER[No after or around advice on handler join points].
-(_CTI_)
-* xref:#CONSTRUCTOR_EXECUTION_IS_BIGGER[Initializers run inside
-constructor execution join points]. (_RTI_)
-* xref:#INTER_TYPE_FIELD_INITIALIZERS[inter-type field initializers] run
-before class-local field initializers. (_RTI_)
-* xref:#WITHIN_MEMBER_TYPES[Small limitations of the within pointcut.]
-(_CRTI_)
-* xref:#WITHIN_CODE[Small limitations of the withincode pointcut.]
-(_CRTI_)
-* xref:#INSTANCEOF_ON_WILD[Can't do instanceof matching on type patterns
-with wildcards]. (_CTI_)
-* xref:#NO_SOURCE_COLUMN[SourceLocation.getColumn() is deprecated and
-will always return 0]. (_RTI_)
-* The interaction between aspect instantiation and advice has been
-xref:#ASPECT_INSTANTIATION_AND_ADVICE[clarified]. (_RTI_)
-* xref:#STRINGBUFFER[The String + operator is now correctly advised].
-(_CRTI_)
-
-[#NEW_LIMITATIONS]#There# are a couple of language limitations for
-things that are rarely used that make the implementation simpler, so we
-have restricted the language accordingly.
-
-* xref:#VOID_FIELD_SET[Field set join points now have a `void` return
-type.] This will require porting of code that uses the `set` PCD in
-conjunction with after-returning or around advice. (_CTI_)
-* 'declare soft: TYPE: POINTCUT;' - AspectJ 1.1 only accepts TYPE rather
-than a TYPE_PATTERN. This limitation makes declare soft much easier to
-implement efficiently. (_CTI_)
-* Inter-type field declarations only allow a single field per line, i.e.
-this is now illegal 'int C.field1, D.field2;' This must instead be, 'int
-C.field1; int D.field2;' (_CTI_)
-* We did not implement the handling of more than one `..` wildcard in
-args PCD's (rarely encountered in the wild) because we didn't have the
-time. This might be available in later releases if there is significant
-outcry. (_CTI_)
-
-We did not implement the long-awaited xref:#PER_TYPE[new pertype aspect
-specifier] in this release, but it may well be in a future release.
-
-'''''
-
-[[compiler]]
-=== The Compiler
-
-The compiler for AspectJ 1.1 is different than the compiler for AspectJ
-1.0. While this document describes the differences in the compiler, it's
-worthwhile noting that much effort has been made to make sure that the
-interface to ajc 1.1 is, as much as possible, the same as the interface
-to ajc 1.0. There are two important changes under the hood, however.
-
-First, the 1.1 compiler is implemented on top of the open-source Eclipse
-compiler. This has two benefits: It allows us to concentrate on the
-AspectJ extensions to Java and let the Eclipse team worry about making
-sure the Java edge cases work, and it allows us to piggyback on
-Eclipse's already mature incremental compilation facilities.
-
-Second, ajc now cleanly delineates compilation of source code from
-assembly (or "weaving") of bytecode. The compiler still accepts source
-code, but internally it transforms it into bytecode format before
-weaving.
-
-This new architecture, and other changes to the compiler, allows us to
-implement some features that were defined in the AspectJ 1.0 language
-but not implementable in the 1.1 compiler. It also makes some new
-features available:
-
-* xref:#SOURCEROOT[The -sourceroots option] takes one or more
-directories, and indicates that all the source files in those
-directories should be passed to the compiler.
-* xref:#BYTECODE_WEAVING[The -injars option] takes one or more jar
-files, and indicates that all the classfiles in the jar files should be
-woven into.
-* xref:#BINARY_ASPECTS[The -aspectpath option] takes one or more jar
-files, and weaves any aspects in .class form into the sources.
-* xref:#OUTJAR[The -outjar option] indicates that the result classfiles
-of compiling and weaving should be placed in the specified jar file.
-* xref:#XLINT[The -Xlint option] allows control over warnings.
-* xref:#OTHER_X_OPTIONS[Various -X options] changed.
-* xref:#INCREMENTAL[The -incremental option] tells the AspectJ 1.1
-compiler to recompile only as necessary.
-
-Some other features we wanted to support for 1.1, but did not make it
-into this release:
-
-* xref:#ERROR_MESSAGES[Error messages will sometimes be scary]
-* xref:#MESSAGE_CONTEXT[Source code context is not shown for errors and
-warnings detected during bytecode weaving]
-
-But some features of the 1.0 compiler are not supported in the 1.1
-compiler:
-
-* xref:#NO_SOURCE[The source-related options] -preprocess, -usejavac,
--nocomment and -workingdir
-* xref:#NO_STRICT_LENIENT[The -strict and -lenient options]
-* xref:#NO_PORTING[The -porting option]
-* xref:#_13_REQUIRED[J2SE 1.2 is not supported; J2SE 1.3 or later is
-required.]
-
-A short description of the options ajc accepts is available with
-"`ajc -help`". Longer descriptions are available in the
-link:devguide/ajc-ref.html[Development Environment Guide section on
-ajc].
-
-Some changes to the implementation are almost entirely internal:
-
-* The behavior of the compiler in xref:#TARGET_TYPES_MADE_PUBLIC[lifting
-the visibility] of the target types of some declares and pointcuts to
-public has been clarified.
-
-Also, it is worth noting that because AspectJ now works on bytecode, it
-is somewhat sensitive to how different compilers generate bytecode,
-especially when compiling with and without
-xref:#ONE_FOUR_METHOD_SIGNATURES[the -1.4 flag].
-
-'''''
-
-[[tools]]
-=== Support Tools
-
-This release includes an Ant task for old-style 1.0 build scripts, a new
-task for all the new compiler options, and a CompilerAdapter to support
-running `ajc` with the Javac task by setting the `build.compiler`
-property. The new task can automatically copy input resources to output
-and work in incremental mode using a "tag" file.
-
-This release does not include `ajdoc`, the documentation tool for
-AspectJ sources. Ajdoc is deeply dependent on the abstract syntax tree
-classes from the old compiler, so it needs a bottom-up rewrite. We think
-it best to use this opportunity to implement more general API's for
-publishing and rendering static structure. Because those API's are last
-to settle in the new architecture, and because the compiler itself is a
-higher priority, we are delaying work on ajdoc until after the 1.1
-release.
-
-AspectJ 1.1 will not include ajdb, the AspectJ stand-alone debugger. It
-is no longer necessary for two reasons. First, the -XnoInline flag will
-tell the compiler to generate code without inlining that should work
-correctly with any Java debugger. For code generated with inlining
-enabled, more third-party debuggers are starting to work according to
-JSR 45, "Debugging support for other languages," which is supported by
-AspectJ 1.0. We aim to support JSR-45 in AspectJ 1.1, but support will
-not be in the initial release. Consider using the -XnoInline flag until
-support is available.
-
-'''''
-
-[[runtime]]
-=== The Runtime Library
-
-This release has minor additions to the runtime library classes. As with
-any release, you should compile and run with the runtime library that
-came with your compiler, and you may run with a later version of the
-library without recompiling your code.
-
-In one instance, however, runtime classes behave differently this
-release. Because the AspectJ 1.1 compiler does its weaving through
-bytecode, column numbers of source locations are not available.
-Therefore, `thisJoinPoint.getSourceLocation().getColumn()` is deprecated
-and will always return 0.
-
-'''''
-
-[[devenv]]
-=== The AJDE Tools
-
-The AspectJ Browser supports incremental compilation and running
-programs. AJDE for JBuilder, AJDE for NetBeans, and AJDE for Emacs are
-now independent SourceForge projects (to keep their licenses). They use
-the batch-build mode of the new compiler.
-
-'''''
-
-[[sources]]
-=== The Sources and the Licenses
-
-The AspectJ tools sources are available under the
-https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.txt[Eclipse Public
-License v 2.0] in the Git repository at https://eclipse.org/aspectj. For
-more information, see the FAQ entry on building sources.
-
-'''''
-
-[[distribution]]
-=== The AspectJ distribution
-
-AspectJ 1.0 had many distributions - for the tools, the documentation,
-each IDE support package, their respective sources, and the Ant tasks -
-because they came under different licenses. All of AspectJ 1.1 is
-licensed under the CPL 1.0, so the tools, Ant tasks, and documentation
-are all in one distribution available from https://eclipse.org/aspectj.
-To retain their MPL 1.1 license, Ajde for
-http://aspectj4emacs.sourceforge.net/[Emacs],
-http://aspectj4netbean.sourceforge.net/[NetBeans] and
-http://aspectj4jbuildr.sourceforge.net/[JBuilder] are now independent
-SourceForge projects.
-
-'''''
-
-'''''
-
-[[details]]
-=== Details of some language and compiler changes
-
-[[ASPECT_INSTANTIATION_AND_ADVICE]]
-==== Aspect Instantiation and Advice
-
-In AspectJ 1.0.6, we made an effort to hide some complications with
-Aspect instantiation from the user. In particular, the following code
-compiled and ran:
-
-[source, java]
-....
-public class Client {
-    public static void main(String[] args) {
-        Client c = new Client();
-    }
-}
-
-aspect Watchcall {
-    pointcut myConstructor(): execution(new(..));
-
-    before(): myConstructor() {
-        System.err.println("Entering Constructor");
-    }
-}
-....
-
-But there's a conceptual problem with this code: The before advice
-should run before the execution of all constructors in the system. It
-must run in the context of an instance of the Watchcall aspect. The only
-way to get such an instance is to have Watchcall's default constructor
-execute. But before that executes, we need to run the before advice...
-
-AspectJ 1.0.6 hid this circularity through the ad-hoc mechanism of
-preventing an aspect's advice from matching join points that were within
-the aspect's definition, and occurred before the aspect was initialized.
-But even in AspectJ 1.0.6, this circularity could be exposed:
-
-[source, java]
-....
-public class Client {
-    public static int foo() { return 3; }
-    public static void main(String[] args) {
-        Client c = new Client();
-    }
-}
-
-aspect Watchcall {
-    int i = Client.foo();
-    pointcut myConstructor():
-        execution(new(..)) || execution(int foo());
-
-    before(): myConstructor() {
-        System.err.println("Entering Constructor");
-    }
-}
-....
-
-This program would throw a NullPointerException when run, since
-Client.foo() was called before the Watchcall instance could be
-instantiated.
-
-In AspectJ 1.1, we have decided that half-hiding the problem just leads
-to trouble, and so we are no longer silently hiding some join points
-before aspect initialization. However, we have provided a better
-exception than a NullPointerException for this case. In AspectJ 1.1,
-both of the above programs will throw
-org.aspectj.lang.NoAspectBoundException.
-
-[[THROWS_PATTERN]]
-==== Matching based on throws
-
-Type patterns may now be used to pick out methods and constructors based
-on their throws clauses. This allows the following two kinds of
-extremely wildcarded pointcuts:
-
-[source, java]
-....
-pointcut throwsMathlike():
-  // each call to a method with a throws clause containing at least
-  // one exception with "Math" in its name.
-  call(* *(..) throws *..*Math*);
-
-pointcut doesNotThrowMathlike():
-  // each call to a method with a throws clause containing no
-  // exceptions with "Math" in its name.
-  call(* *(..) throws !*..*Math*);
-....
-
-The longwinded rules are that a method or constructor pattern can have a
-"throws clause pattern". Throws clause patterns look like:
-
-[source, text]
-....
-ThrowsClausePattern:
-    ThrowsClausePatternItem ("," ThrowsClausePatternItem)*
-
-ThrowsClausePatternItem:
-    ["!"] TypeNamePattern
-....
-
-A ThrowsClausePattern matches the ThrowsClause of any code member
-signature. To match, each ThrowsClausePatternItem must match the throws
-clause of the member in question. If any item doesn't match, then the
-whole pattern doesn't match. This rule is unchanged from AspectJ 1.0.
-
-If a ThrowsClausePatternItem begins with "!", then it matches a
-particular throws clause if and only if _none_ of the types named in the
-throws clause is matched by the TypeNamePattern.
-
-If a ThrowsClausePatternItem does not begin with "!", then it matches a
-throws clause if and only if _any_ of the types named in the throws
-clause is matched by the TypeNamePattern.
-
-These rules are completely backwards compatible with AspectJ 1.0. The
-rule for "!" matching has one potentially surprising property, in that
-the two PCD's shown below will have different matching rules.
-
-[source, java]
-....
-/*[1]*/ call(* *(..) throws !IOException)
-/*[2]*/ call(* *(..) throws (!IOException))
-
-void m() throws RuntimeException, IOException {}
-....
-
-[1] will NOT match the method m(), because method m's throws clause
-declares that it throws IOException. [2] WILL match the method m(),
-because method m's throws clause declares the it throws some exception
-which does not match IOException, i.e. RuntimeException.
-
-[[NEW_PCDS]]
-==== New kinded pointcut designators
-
-AspectJ 1.0 does not provide kinded pointcut designators for two (rarely
-used) join points: preinitialization (the code that runs before a super
-constructor call is made) and advice execution. AspectJ 1.1 does not
-change the meaning of the join points, but provides two new pointcut
-designators to pick out these join points, thus making join points and
-pointcut designators more parallel.
-
-`adviceexectuion()` will pick out advice execution join points. You will
-usually want to use `adviceexecution()     && within(Aspect)` to
-restrict it to only those pieces of advice defined in a particular
-aspect. +
-`preinitialization(ConstructorPattern)` will pick out pre-initialization
-join points where the initialization process is entered through
-`ConstructorPattern`.
-
-[[PER_TYPE]]
-==== New pertype aspect specifier (not in 1.1)
-
-We strongly considered adding a pertype aspect kind to 1.1. This is
-somewhat motivated by the new
-xref:#SINGLE_INTERCLASS_TARGET[restrictions on inter-type declarations]
-
-. This is also motivated by many previous request to support a common
-logging idiom. Here's what pertype would look like:
-
-[source, java]
-....
-/** One instance of this aspect will be created for each class,
- * interface or aspect in the com.bigboxco packages.
- */
-aspect Logger pertype(com.bigboxco..*) {
-    /* This field holds a logger for the class. */
-    Log log;
-
-    /* This advice will run for every public execution defined by
-     * a type for which a Logger aspect has been created, i.e.
-     * any type in com.bigboxco..*
-     */
-    before(): execution(public * *(..)) {
-        log.enterMethod(thisJoinPoint.getSignature().getName());
-    }
-
-    /* We can use a special constructor to initialize the log field */
-    public Logger(Class myType) {
-        this.log = new Log(myType);
-    }
-}
-
-/** External code could use aspectOf to get at the log, i.e. */
-Log l = Logger.aspectOf(com.bigboxco.Foo.class).log;
-....
-
-The one open question that we see is how this should interact with inner
-types. If a pertype aspect is created for an outer type should advice in
-that aspect run for join points in inner types? That is the behavior of
-the most common uses of this idiom.
-
-In any case, this feature will not be in AspectJ 1.1.
-
-[[SINGLE_INTERCLASS_TARGET]]
-==== One target for intertype declarations
-
-Intertype declarations (once called "introductions") in AspectJ 1.1 can
-only have one target type. So the following code intended to declare
-that there is a void doStuff() method on all subtypes of Target is not
-legal AspectJ 1.1 code.
-
-[source, java]
-....
-aspect A {
-    public void Target+.doStuff() { ... }
-}
-....
-
-The functionality of "multi-intertype declarations" can be recovered by
-using a helper interface.
-
-[source, java]
-....
-aspect A {
-    private interface MyTarget {}
-    declare parents:  Target+ implements MyTarget;
-    public void MyTarget.doStuff() { ... }
-}
-....
-
-We believe this is better style in AspectJ 1.0 as well, as it makes
-clear the static type of "this" inside the method body.
-
-The one piece of functionality that can not be easily recovered is the
-ability to add static fields to many classes. We believe that the
-xref:#PER_TYPE[pertype proposal] provides this functionality in a much
-more usable form.
-
-[[UNAVAILABLE_JOIN_POINTS]]
-==== No initializer execution join points
-
-AspectJ 1.1 does not consider initializer execution a principled join
-point. The collection of initializer code (the code that sets fields
-with initializers and the code in non-static initializer blocks) is
-something that makes sense only in Java source code, not in Java
-bytecode.
-
-[[AFTER_HANDLER]]
-==== No after or around advice on handler join points
-
-The end of an exception handler is underdetermined in bytecode, so ajc
-will not implement after or around advice on handler join points,
-instead signaling a compile-time error.
-
-[[CONSTRUCTOR_EXECUTION_IS_BIGGER]]
-==== Initializers run inside constructor execution join points
-
-The code generated by the initializers in Java source code now runs
-inside of constructor execution join points. This changes how before
-advice runs on constructor execution join points. Consider:
-
-[source, java]
-....
-class C {
-    C() { }
-    String id = "identifier"; // this assignment
-                              // has to happen sometime
-}
-
-aspect A {
-    before(C c) this(c) && execution(C.new()) {
-        System.out.println(c.id.length());
-    }
-}
-....
-
-In AspectJ 1.0, this will print "10", since id is assigned its initial
-value prior to the before advice's execution. However, in AspectJ 1.1,
-this will throw a NullPointerExcception, since "id" does not have a
-value prior to the before advice's execution.
-
-Note that the various flavors of after returning advice are unchanged in
-this respect in AspectJ 1.1. Also note that this only matters for the
-execution of constructors that call a super-constructor. Execution of
-constructors that call a this-constructor are the same in AspectJ 1.1 as
-in AspectJ 1.0.
-
-We believe this difference should be minimal to real programs, since
-programmers using before advice on constructor execution must always
-assume incomplete object initialization, since the constructor has not
-yet run.
-
-[[INTER_TYPE_FIELD_INITIALIZERS]]
-==== Inter-type field initializers
-
-The initializer, if any, of an inter-type field definition runs before
-the class-local initializers of its target class.
-
-In AspectJ 1.0.6, such an initializer would run after the initializers
-of a class but before the execution of any of its constructor bodies. As
-already discussed in the sections about
-xref:#UNAVAILABLE_JOIN_POINTS[initializer execution join points] and
-xref:#CONSTRUCTOR_EXECUTION_IS_BIGGER[constructor execution], the point
-in code between the initializers of a class and its constructor body is
-not principled in bytecode. So we had a choice of running the
-initializer of an inter-type field definition at the beginning of
-initialization (i.e., before initializers from the target class) or at
-the end (i.e., just before its called constructor exits). We chose the
-former, having this pattern in mind:
-
-[source, java]
-....
-int C.methodCount = 0;
-before(C c): this(c) && execution(* *(..)) { c.methodCount++; }
-....
-
-We felt there would be too much surprise if a constructor called a
-method (thus incrementing the method count) and then the field was reset
-to zero after the constructor was done.
-
-[[WITHIN_MEMBER_TYPES]]
-==== Small limitations of the within pointcut
-
-Because of the guarantees made (and not made) by the Java classfile
-format, there are cases where AspectJ 1.1 cannot guarantee that the
-within pointcut designator will pick out all code that was originally
-within the source code of a certain type.
-
-The non-guarantee applies to code inside of anonymous and local types
-inside member types. While the within pointcut designator behaves
-exactly as it did in AspectJ 1.0 when given a package-level type (like
-C, below), if given a member-type (like C.InsideC, below), it is not
-guaranteed to capture code in contained local and anonymous types. For
-example:
-
-[source, java]
-....
-class C {
-    Thread t;
-    class InsideC {
-        void setupOuterThread() {
-            t = new Thread(
-                    new Runnable() {
-                        public void run() {
-                            // join points with code here
-                            // might not be captured by
-                            // within(C.InsideC), but are
-                            // captured by within(C)
-                            System.out.println("hi");
-                        }
-                    });
-        }
-    }
-}
-....
-
-We believe the non-guarantee is small, and we haven't verified that it
-is a problem in practice.
-
-[[WITHIN_CODE]]
-==== Small limitations of the withincode pointcut
-
-The withincode pointcut has similar issues to those described above for
-within.
-
-[[INSTANCEOF_ON_WILD]]
-==== Can't do instanceof matching on type patterns with wildcard
-
-The pointcut designators this, target and args specify a dynamic test on
-their argument. These tests can not be performed on type patterns with
-wildcards in them. The following code that compiled under 1.0 will be an
-error in AspectJ-1.1:
-
-[source, java]
-....
-pointcut oneOfMine(): this(com.bigboxco..*);
-....
-
-The only way to implement this kind of matching in a modular way would
-be to use the reflection API at runtime on the Class of the object. This
-would have a very high performance cost and possible security issues.
-There are two good work-arounds. If you control the source or bytecode
-to the type you want to match then you can use declare parents, i.e.:
-
-[source, java]
-....
-private interface OneOfMine {}
-declare parents: com.bigboxco..* implements OneOfMine;
-pointcut oneOfMine(): this(OneOfMine);
-....
-
-If you want the more dynamic matching and are willing to pay for the
-performance, then you should use the Java reflection API combined with
-if. That would look something like:
-
-[source, java]
-....
-pointcut oneOfMine(): this(Object) &&
-    if(classMatches("com.bigboxco..*",
-                    thisJoinPoint.getTarget().getClass()));
-
-static boolean classMatches(String pattern, Class _class) {
-    if (patternMatches(pattern, _class.getName())) return true;
-    ...
-}
-....
-
-Note: wildcard type matching still works in all other PCD's that match
-based on static types. So, you can use 'within(com.bigboxco..*+)' to
-match any code lexically within one of your classes or a subtype
-thereof. This is often a good choice.
-
-[[NO_SOURCE_COLUMN]]
-==== SourceLocation.getColumn()
-
-The Java .class file format contains information about the source file
-and line numbers of its contents; however, it has no information about
-source columns. As a result, we can not effectively support the access
-of column information in the reflection API. So, any calls to
-thisJoinPoint.getSourceLocation().getColumn() will be marked as
-deprecated by the compiler, and will always return 0.
-
-[[ASPECT_PRECEDENCE]]
-==== Aspect precedence
-
-AspectJ 1.1 has a new declare form:
-
-[source, java]
-....
-declare precedence ":"  TypePatternList ";"
-....
-
-This is used to declare advice ordering constraints on join points. For
-example, the constraints that (1) aspects that have Security as part of
-their name should dominate all other aspects, and (2) the Logging aspect
-(and any aspect that extends it) should dominate all non-security
-aspects, can be expressed by:
-
-[source, java]
-....
-declare precedence: *..*Security*, Logging+, *;
-....
-
-In the TypePatternList, the wildcard * means "any type not matched by
-another type in the declare precedence".
-
-===== Various cycles
-
-It is an error for any aspect to be matched by more than one TypePattern
-in a single declare precedence, so:
-
-[source, java]
-....
-declare precedence:  A, B, A ;  // error
-....
-
-However, multiple declare precedence forms may legally have this kind of
-circularity. For example, each of these declare precedence is perfectly
-legal:
-
-[source, java]
-....
-declare precedence: B, A;
-declare precedence: A, B;
-....
-
-And a system in which both constraints are active may also be legal, so
-long as advice from A and B don't share a join point. So this is an
-idiom that can be used to enforce that A and B are strongly independent.
-
-===== Applies to concrete aspects
-
-Consider the following library aspects:
-
-[source, java]
-....
-abstract aspect Logging {
-    abstract pointcut logged();
-
-    before(): logged() {
-        System.err.println("thisJoinPoint: " + thisJoinPoint);
-    }
-}
-
-aspect MyProfiling {
-    abstract pointcut profiled();
-
-    Object around(): profiled() {
-        long beforeTime = System.currentTimeMillis();
-        try {
-            return proceed();
-        } finally {
-            long afterTime = System.currentTimeMillis();
-            addToProfile(thisJoinPointStaticPart,
-                         afterTime - beforeTime);
-        }
-    }
-    abstract void addToProfile(
-        org.aspectj.JoinPoint.StaticPart jp,
-        long elapsed);
-}
-....
-
-In order to use either aspect, they must be extended with concrete
-aspects, say, MyLogging and MyProfiling. In AspectJ 1.0, it was not
-possible to express that Logging's advice (when concerned with the
-concrete aspect MyLogging) dominated Profiling's advice (when concerned
-with the concrete aspect MyProfiling) without adding a dominates clause
-to Logging itself. In AspectJ 1.1, we can express that constraint with a
-simple:
-
-[source, java]
-....
-declare precedence: MyLogging, MyProfiling;
-....
-
-===== Changing order of advice for sub-aspects
-
-By default, advice in a sub-aspect has more precedence than advice in a
-super-aspect. One use of the AspectJ 1.0 dominates form was to change
-this precedence:
-
-[source, java]
-....
-abstract aspect SuperA dominates SubA {
-    pointcut foo(): ... ;
-
-    before(): foo() {
-        // in AspectJ 1.0, runs before the advice in SubA
-        // because of the dominates clause
-    }
-}
-
-aspect SubA extends SuperA {
-    before(): foo() {
-        // in AspectJ 1.0, runs after the advice in SuperA
-        // because of the dominates clause
-    }
-}
-....
-
-This no longer works in AspectJ 1.1, since declare precedence only
-matters for concrete aspects. Thus, if you want to regain this kind of
-precedence change, you will need to refactor your aspects.
-
-[[SOURCEROOT]]
-==== The -sourceroots option
-
-The AspectJ 1.1 compiler now accepts a -sourceroots option used to pass
-all .java files in particular directories to the compiler. It takes
-either a single directory name, or a list of directory names separated
-with the CLASSPATH separator character (":" for various Unices, ";" for
-various Windows).
-
-So, if you have your project separated into a gui module and a base
-module, each of which is stored in a directory tree, you might use one
-of
-
-[source, text]
-....
-ajc -sourceroots /myProject/gui:/myProject/base
-ajc -sourceroots d:\myProject\gui;d:\myProject\base
-....
-
-This option may be used in conjunction with lst files, listing .java
-files on the command line, and the -injars option.
-
-[[BYTECODE_WEAVING]]
-==== The -injars option
-
-The AspectJ 1.1 compiler now accepts an -injars option used to pass all
-.class files in a particular jar file to the compiler. It takes either a
-single directory name, or a list of directory names separated with the
-CLASSPATH separator character (":" for various Unices, ";" for various
-Windows).
-
-So, if MyTracing.java defines a trace aspect that you want to apply to
-all the classes in myBase.jar and myGui.jar, you would use one of:
-
-[source, text]
-....
-ajc -injars /bin/myBase.jar:/bin/myGui.jar MyTracing.java
-ajc -injars d:\bin\myBase.jar;d:\bin\myGui.jar MyTracing.java
-....
-
-The class files in the input jars must not have had advice woven into
-them, since AspectJ enforces the requirement that advice is woven into a
-particular classfile only once. So if the classfiles in the jar file are
-to be created with the ajc compiler (as opposed to a pure Java
-compiler), they should not be compiled with any non-abstract aspects.
-
-This option may be used in conjunction with lst files, listing .java
-files on the command line, and the -sourceroots option.
-
-[[OUTJAR]]
-==== The -outjar option
-
-The -outjar option takes the name of a jar file into which the results
-of the compilation should be put. For example:
-
-[source, text]
-....
-ajc -injars myBase.jar MyTracing.java -outjar myTracedBase.jar
-....
-
-No meta information is placed in the output jar file.
-
-[[INCREMENTAL]]
-==== Incremental compilation
-
-The AspectJ 1.1 compiler now supports incremental compilation. When ajc
-is called with the -incremental option, it must also be passed a
--sourceroots option specifying a directory to incrementally compile.
-Once the initial compile is done, ajc waits for console input. Every
-time it reads a new line (i.e., every time the user hits return) ajc
-recompiles those input files that need recompiling.
-
-===== Limitations
-
-This new functionality is still only lightly tested.
-
-[[XNOWEAVE]]
-==== -XnoWeave, a compiler option to suppress weaving
-
-The -XnoWeave option suppresses weaving, and generates classfiles and
-that can be passed to ajc again (through the -injars option) to generate
-final, woven classfiles.
-
-This option was originally envisioned to be the primary way to generate
-binary aspects that could be linked with other code, and so it was
-previously (in AspectJ 1.1beta1) named `-noweave`. We feel that using
-the `-aspectpath` option is a much better option. There may still be use
-cases for unwoven classfiles, but we've moved the flag to experimental
-status.
-
-[[BINARY_ASPECTS]]
-==== -aspectpath, working with aspects in .class/.jar form
-
-When aspects are compiled into classfiles, they include all information
-necessary for the ajc compiler to weave their advice and deal with their
-inter-type declarations. In order for these aspects to have an effect on
-a compilation process, they must be passed to the compiler on the
--aspectpath. Every .jar file on this path will be searched for aspects
-and any aspects that are found will be enabled during the compilation.
-The binary forms of this aspects will be untouched.
-
-[[NO_CALLEE_SIDE_CALL]]
-==== Callee-side call join points
-
-The 1.0 implementation of AspectJ, when given:
-
-[source, java]
-....
-class MyRunnable implements Runnable {
-    public void run() { /*...*/ }
-}
-
-aspect A {
-    call(): (void run()) && target(MyRunnable) {
-        // do something here
-    }
-}
-....
-
-would cause A's advice to execute even when, say, java.lang.Thread
-called run() on a MyRunnable instance.
-
-With the new compiler, two things have happened in regard to callee-side
-calls:
-
-. because the programmer has access to more code (i.e., bytecode, not
-just source code), callee-side calls are much less important to have.
-. because compilation is more modular, allowing and encouraging separate
-compilation, callee-side calls are much more difficult to implement
-
-With these two points in mind, advice in an aspect will not be applied
-to call join points whose call site is completely unavailable to the
-aspect.
-
-. One reason (though not the only reason) we worked so hard in the
-_implementation_ of 1.0.6 to expose call join points, even if we only
-had access to the callee's code, was that otherwise users couldn't get
-access to call join points where the call was made from bytecode. This
-is no longer the case. In short, the implementation controls much more
-code (or has the capability to) than ever before.
-. The implementation model for the AspectJ 1.1 compiler is to separate
-the compilation of aspects/advice from their weaving/linking. A property
-of the model is that the compilation requires no access to "target"
-code, only the weaving/linking does, and weaving/linking is inherently
-per-class local: No action at weaving/linking time depends on the
-coordinated mangling of multiple classfiles. Rather, all weaving is done
-on a per classfile basis. This is an essential property for the current
-separate compilation model. +
-However, allowing implementation of call advice on either side requires
-simultaneous knowledge of both sides. If we first have access to a call,
-we can't decide to simply put the advice on the call site, since later
-we may decide to implement on the callee.
-
-This implementation decision is completely in the letter and the spirit
-of the AspectJ language. From the semantics guide describing code the
-implementation controls:
-
-____
-But AspectJ implementations are permitted to deviate from this in a
-well-defined way -- they are permitted to advise only accesses in _code
-the implementation controls_. Each implementation is free within certain
-bounds to provide its own definition of what it means to control code.
-____
-
-And about a particular decision about the 1.0.6 implementation:
-
-____
-Different join points have different requirements. Method call join
-points can be advised only if ajc controls _either_ the code for the
-caller or the code for the receiver, and some call pointcut designators
-may require caller context (what the static type of the receiver is, for
-example) to pick out join points.
-____
-
-The 1.1 implementation makes a different design decision: Method call
-join points can be advised only if ajc (in compiler or linker form)
-controls the code for the caller.
-
-What does 1.1 gain from this?
-
-* a clear (and implemented) separate compilation model (see point 2,
-above)
-* a less confusing interaction between call join points and the
-thisJoinPoint reflective object: We still get bug reports about source
-information sometimes existing and sometimes not existing at call join
-points.
-
-What does 1.1 lose from this?
-
-* The ability to capture all calls to Runnable.run() from anywhere to
-code ajc has access too, even from Thread, even if you don't compile
-java.lang with ajc.
-* The ability to, without access to the caller, capture entry to a
-particular method, but not super calls.
-* A code-size-improvement performance optimization.
-
-What are the possibilities for the future?
-
-* AspectJ 1.1.1 could expand its capture of call join points, possibly
-at the expense of separate compilation clarity, possibly not.
-* AspectJ 1.1.1 could re-introduce reception join points from AspectJ
-0.7 (what callee-side call join points actually are): though they would
-never ever be taught in a tutorial or entry-level description of the
-model, they may have specialized uses.
-
-How will this affect developers?
-
-* When using the call PCD but only supplying the callee code, supply the
-calling code or use the execution PCD instead.
-
-[[OTHER_X_OPTIONS]]
-==== Various -X options
-
-The AspectJ 1.0 compiler supported a number of options that started with
-X, for "experimental". Some of them will not be supported in 1.1, either
-because the "experiment" succeeded (in which case it's part of the
-normal functionality) or failed. Others will be supported as is (or
-nearly so) in 1.1:
-
-* -XOcodeSize: This is no longer necessary because inlining of around
-advice is on by default. We support its inverse,
-xref:#XNOINLINE[`-XnoInline`].
-* xref:#XNOWEAVE[-XnoWeave, a compiler option to suppress weaving]
-* -XtargetNearSource: Not supported in this release.
-* -XserializableAspects: Supported.
-* -XaddSafePrefix: This option will not be supported in 1.1 at all
-because we're now always using (what we believe to be) safe prefixes.
-* -Xlint: Still supported, with xref:#XLINT[various options].
-
-[[ERROR_MESSAGES]]
-==== Some confusing error messages
-
-Building on the eclipse compiler has given us access to a very
-sophisticated problem reporting system as well as highly optimized error
-messages for pure Java code. Often this leads to noticeably better error
-messages than from ajc-1.0.6. However, when we don't handle errors
-correctly this can sometimes lead to cascading error messages where a
-single small syntax error will produce dozens of other messages. Please
-report any very confusing error messages as bugs.
-
-[[MESSAGE_CONTEXT]]
-==== Source code context is not shown for errors and warnings detected during bytecode weaving
-
-For compiler errors and warnings detected during bytecode weaving,
-source code context will not be displayed. In particular, for declare
-error and declare warning statements, the compiler now only emits the
-file and line. We are investigating ways to overcome this in cases where
-the source code is available; in cases where source code is not
-available, we might specify the signature of the offending code. For
-more information, see bug 31724.
-
-[[XLINT]]
-==== The -Xlint option
-
-`-Xlint:ignore,error,warning` will set the level for all Xlint warnings.
-`-Xlint`, alone, is an abbreviation for `-Xlint:warning`.
-
-The `-Xlintfile:lint.properties` allows fine-grained control. In
-tools.jar, see `org/aspectj/weaver/XlintDefault.properties` for the
-default behavior and a template to copy.
-
-More `-Xlint` warnings are supported now, and we may add disabled
-warnings in subsequent bug-fix releases of 1.1. Because the
-configurability allows users to turn off warnings, we will be able to
-warn about more potentially dangerous situations, such as the
-potentially unsafe casts used by very polymorphic uses of proceed in
-around advice.
-
-[[NO_SOURCE]]
-==== Source-specific options
-
-Because AspectJ 1.1 does not generate source code after weaving, the
-source-code-specific options -preprocess, -usejavac, -nocomment and
--workingdir options are meaningless and so not supported.
-
-[[NO_STRICT_LENIENT]]
-==== The -strict and -lenient options
-
-Because AspectJ 1.1 uses the Eclipse compiler, which has its own
-mechanism for changing strictness, we no longer support the -strict and
--lenient options.
-
-[[NO_PORTING]]
-==== The -porting option
-
-AspectJ 1.1 does not have a -porting option.
-
-[[_13_REQUIRED]]
-==== J2SE 1.3 required
-
-Because we build on Eclipse, the compiler will no longer run under J2SE
-1.2. You must run the compiler (and all tools based on the compiler)
-using J2SE 1.3 or later. The code generated by the compiler can still
-run on Java 1.1 or later VM's if compiled against the correct runtime
-libraries.
-
-[[DEFAULT_CONSTRUCTOR_CONFLICT]]
-==== Default constructors
-
-AspectJ 1.1 does not allow the inter-type definition of a zero-argument
-constructor on a class with a visible default constructor. So this is no
-longer allowed:
-
-[source, java]
-....
-class C {}
-
-aspect A {
-    C.new() {}  // was allowed in 1.0.6
-                // is a "multiple definitions" conflict in 1.1
-}
-....
-
-In the Java Programming Language, a class defined without a constructor
-actually has a "default" constructor that takes no arguments and just
-calls `super()`.
-
-This default constructor is a member of the class like any other member,
-and can be referenced by other classes, and has code generated for it in
-classfiles. Therefore, it was an oversight that AspectJ 1.0.6 allowed
-such an "overriding" inter-type constructor definition.
-
-[[SUPER_IFACE_INITS]]
-==== Initialization join points for super-interfaces
-
-In AspectJ, interfaces may have non-static members due to inter-type
-declarations. Because of this, the semantics of AspectJ defines the
-order that initializer code for interfaces is run.
-
-In the semantics document for AspectJ 1.0.6, the following promises were
-made about the order of this initialization:
-
-. a supertype is initialized before a subtype
-. initialized code runs only once
-. initializers for supertypes run in left-to-right order
-
-The first two properties are important and are preserved in AspectJ 1.1,
-but the third property is and was ludicrous, and was never properly
-implemented (and never could be) in AspectJ 1.0.6. Consider:
-
-[source, java]
-....
-interface Top0 {}
-interface Top1 {}
-interface I extends Top0, Top1 {}
-interface J extends Top1, Top0 {}
-
-class C implements I, J {}
-// I says Top0's inits must run before Top1's
-// J says Top1's inits must run before Top0's
-
-aspect A {
-    int Top0.i = foo("I'm in Top0");
-    int Top1.i = foo("I'm in Top1");
-    static int foo(String s) {
-        System.out.println(s);
-        return 37;
-    }
-}
-....
-
-This was simply a bug in the AspectJ specification. The correct third
-rule is:
-
-____
-the initializers for a type's superclass are run before the initializers
-for its superinterfaces.
-____
-
-[[VOID_FIELD_SET]]
-==== Field Set Join Points
-
-In AspectJ 1.0.6, the join point for setting a field F had, as a return
-type, F's type. This was "java compatible" because field assignment in
-java, such as "Foo.i = 37", is in fact an expression, and does in fact
-return a value, the value that the field is assigned to.
-
-This was never "java programmer compatible", however, largely because
-programmers have absorbed the good style of rarely using an assignment
-statement in a value context. Programmers typically expect "Foo.i = 37"
-not to return a value, but to simply assign a value.
-
-Thus, programmers typically wanted to write something like:
-
-[source, java]
-....
-void around(): set(int Foo.i) {
-    if (theSetIsAllowed()) {
-        proceed();
-    }
-}
-....
-
-And were confused by it being a compile-time error. They weren't
-confused for long, and soon adapted to writing:
-
-[source, java]
-....
-int around(): set(int Foo.i) {
-    if (theSetIsAllowed()) {
-        return proceed();
-    } else {
-        return Foo.i;
-    }
-}
-....
-
-But there was definitely a short disconnect.
-
-On top of that, we were never shown a convincing use-case for returning
-an interesting value from a set join point. When we revisited this
-issue, in fact, we realized we had a long-standing bug in 1.0.6 dealing
-with the return value of pre-increment expressions (such as ++Foo.i)
-that nobody had found because nobody cares about the return value of
-such join points.
-
-So, because it's easier to implement, and because we believe that this
-is the last possibility to make the semantics more useful, we have made
-set join points have a void return type in 1.1.
-
-[[XNOINLINE]]
-==== The -XnoInline Option
-
-The `-XnoInline` option to indicate that no inlining of any kind should
-be done. This is purely a compiler pragma: No program semantics (apart
-from stack traces) will be changed by the presence or absence of this
-option.
-
-[[TARGET_TYPES_MADE_PUBLIC]]
-==== Target types made public
-
-Even in 1.0.6, the AspectJ compiler has occasionally needed to convert
-the visibility of a package-level class to a public one. This was
-previously done in an ad-hoc basis that took whole-program analysis into
-account. With the incremental compilation model of AspectJ 1.1, we can
-now specify the occasions when the compiler makes these visibility
-changes.
-
-In particular, the types used in the `this`, `target`, and `args`
-pointcuts are made public, as are the super-types from `declare parents`
-and the exception type from `declare soft`.
-
-We believe the visibility changes could be avoided in the future with
-various implementation tricks if they become a serious concern, but did
-not encounter them as such a concern when they were done in the 1.0.6
-implementation.
-
-[[STRINGBUFFER]]
-==== String + now advised
-
-In Java, the + operator sometimes results in StringBuffer objects being
-created, appended to, and used to generate a new String. Thus,
-
-[source, java]
-....
-class Foo {
-    String makeEmphatic(String s) {
-        return s + "!";
-    }
-}
-....
-
-is approximately the same at runtime as
-
-[source, java]
-....
-class Foo {
-    String makeEmphatic(String s) {
-        return new StringBuffer(s).append("!").toString();
-    }
-}
-....
-
-In the design process of AspectJ 1.0.6 we didn't expose those
-StringBuffer methods and constructors as join points (though we did
-discuss it), but in 1.1 we do.
-
-This change is likely to affect highly wildcarded aspects, and can do so
-in surprising ways. In particular:
-
-[source, java]
-....
-class A {
-    before(int i): call(* *(int)) && args(i) {
-        System.err.println("entering with " + i);
-    }
-}
-....
-
-may result in a stack overflow error, since the argument to println is
-really
-
-[source, java]
-....
-new StringBuffer("entering with ").append(i).toString()
-....
-
-which has a call to StringBuffer.append(int). In such cases, it's worth
-restricting your pointcut, with something like one of:
-
-[source, java]
-....
-call(* *(int)) && args(i) && !within(A)
-call(* *(int)) && args(i) && !target(StringBuffer)
-....
-
-[[ONE_FOUR_METHOD_SIGNATURES]]
-==== The -1.4 flag and method signatures
-
-Consider the following aspect
-
-[source, java]
-....
-public aspect SwingCalls {
-
-    pointcut callingAnySwing(): call(* javax.swing..*+.*(..));
-
-    before(): callingAnySwing() {
-        System.out.println("Calling any Swing");
-    }
-}
-....
-
-And then consider the two statements
-
-[source, java]
-....
-JFrame frame = new JFrame();
-frame.setTitle("Title");
-....
-
-According to the Java Language Specification version 2, the call to
-`frame.setTitle("Title")` should always produce the bytecode for a call
-to `javax.swing.JFrame.setTitle`. However, older compilers (and eclipse
-when run without the `-1.4` flag) will generate the bytecode for a call
-to `java.awt.Frame.setTitle` instead since this method is not overriden
-by JFrame. The AspectJ weaver depends on the correctly generated
-bytecode in order to match patterns like the one you show correctly.
-
-This is a good example of why the pattern
-`call(* *(..)) && target(JFrame)` is the recommended style. In general,
-OO programmers don't want to care about the static type of an object at
-a call site, but only want to know the dynamic instanceof behavior which
-is what the target matching will handle.
-
-[[knownLimitations]]
-=== Known limitations
-
-The AspectJ 1.1.0 release contains a small number of known limitations
-relative to the AspectJ 1.1 language. For the most up-to-date
-information about known limitations in an AspectJ 1.1 release, see the
-bug database at https://bugs.eclipse.org/bugs, especially the open bugs
-for the
-https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Compiler&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED[compiler],
-https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=IDE&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED[IDE
-support],
-https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Doc&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED[documentation],
-and
-https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Ant&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED[Ant
-tasks]. Developers should know about bugs marked with the "info" keyword
-because those bugs reflect failures to implement the 1.1 language
-perfectly. These might be fixed during the 1.1 release cycle; find them
-using the query
-https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&keywords=info
-For ajc's 1.1 implementation limitations, see
-link:progguide/implementation.html[Programming Guide Appendix:
-"Implementation Notes"].
diff --git a/docs/dist/doc/README-12.adoc b/docs/dist/doc/README-12.adoc
deleted file mode 100644
index 0cbc3b93c..000000000
--- a/docs/dist/doc/README-12.adoc
+++ /dev/null
@@ -1,568 +0,0 @@
-== AspectJ 1.2
-
-_© Copyright 2003,2004 Contributors. All rights reserved._
-
-The definition of the AspectJ language is unchanged in the 1.2 release.
-Instead, AspectJ 1.2 provides major improvements to the functionality of
-the supporting tools and enforces some language limits that went
-unchecked before. This document describes the tools differences between
-AspectJ versions 1.2 and 1.1.1. Users new to AspectJ need only read the
-link:progguide/index.html[AspectJ Programming Guide] since it describes
-the 1.2 language. Users familiar with AspectJ 1.1 may find this document
-a quicker way to learn what changed in the tools, and should use it as a
-guide for porting programs from 1.1 to 1.2, together with porting.html.
-
-This document first summarizes changes from the 1.1.1 release in
-
-* xref:#compiler[the compiler],
-* xref:#tools[the support tools],
-* xref:#runtime[the runtime],
-* xref:#devenv[the development environment support],
-
-then xref:#details[details] some of the changes, and finally points
-readers to the bug database for xref:#allchanges[all the changes].
-
-'''''
-
-[[compiler]]
-=== The Compiler
-
-Compared to AspectJ 1.1.1, the AspectJ 1.2 compiler...
-
-* xref:#WEAVE_TIME[Is faster], with weaving completing in less than half
-the time it used to take in many cases.
-[#WEAVE_CHART]#image:images/AspectJ11v12.JPG[image]#.
-* Supports the xref:#LAZY_TJP[-XlazyTjp option] which produces code that
-runs faster and uses less memory in some common cases.
-* Has xref:#INCREMENTAL[much better support for incremental
-compilation].
-* Produces xref:#ERROR_MESSAGES[better error messages].
-* Has some xref:#LINT[new lint warnings] to catch common mistakes and
-changes to serializability.
-* Supports the xref:#REWEAVABLE[-Xreweavable option] that allows classes
-to be woven more than once.
-* {blank}
-* Supports the xref:#INPATH[-inpath option] which allows both
-directories and jars containing class files to be specified as input to
-the weaver.
-* xref:#COMPLIANCE[Changes the default compiler compliance mode] from
--1.3 to -1.4.
-
-A short description of the options ajc accepts is available with
-"`ajc -help`". Longer descriptions are available in the
-link:devguide/ajc-ref.html[Development Environment Guide section on
-ajc].
-
-'''''
-
-[[tools]]
-=== Support Tools
-
-AspectJ 1.2 contains two important changes to the supporting tools:
-
-* xref:#AJDOC[ajdoc] is back
-* A sample script is supplied for xref:#LTW[load-time weaving] from the
-command-line.
-
-'''''
-
-[[runtime]]
-=== The Runtime Library
-
-This release has minor updates to the runtime library classes. As with
-any release, you should compile and run with the runtime library that
-came with your compiler, and you may run with a later version of the
-library without recompiling your code.
-
-* xref:#SOFTEX[`SoftException`] now supports `getCause()`.
-* Although not part of `aspectjrt.jar` this release also provides a new
-set of tools APIs in the xref:#LTW2[`org.aspectj.weaver.tools`] that
-provide a weaving class loader and an adapter that can be used to
-integrate load-time weaving into an existing class loader hierarchy.
-* Cflow stack management has been modified to use thread local storage
-on JVMs that support this feature. This improves performance in terms of
-heap usage for multi-threaded applications that use cflow.
-
-'''''
-
-[[devenv]]
-=== The AJDE Tools
-
-The AJDE based tools for JBuilder, NetBeans and Emacs continue to be
-independent SourceForge projects. The AspectJ 1.2 distribution includes
-an updated version of the AjBrowser tool that benefits from all the
-enhancements made in the 1.2 compiler.
-
-The 1.2 release of AspectJ also lays a lot of the groundwork for a much
-better AspectJ IDE experience that we hope to surface initially through
-AJDT (AspectJ support for Eclipse). Amongst the many improvements, we
-will have full eager parsing support that avoids the need to keep the
-whole structure model of a project in memory, hopefully making AJDT much
-less memory hungry and much slicker to use. For more details see the
-https://www.eclipse.org/ajdt[AJDT project website].
-
-'''''
-
-[[details]]
-=== Details of some compiler changes
-
-[[WEAVE_TIME]]
-==== Compilation (weave) times reduced.
-
-Our benchmark suite shows that AspectJ 1.2 is at least twice as fast in
-the weaving phase as AspectJ 1.1.1 for matches based on a variety of
-pointcut expressions (see the xref:#WEAVE_CHART[chart above]). We've
-also made the base incremental compilation implementation in AspectJ 1.2
-approximately twice as fast as in AspectJ 1.1.1, so when this is
-combined with the weave time improvements you should see speed-ups of up
-to 4x for incremental compilation.
-
-In addition, AspectJ 1.2 maintains only weak references to some of its
-recoverable data structures, allowing the JVM to optimise between
-performance and memory usage. Experiments forcing GC showed that we can
-achieve about a 20% memory usage reduction in this manner if needed.
-
-[[LAZY_TJP]]
-==== The -XlazyTjp option.
-
-Under AspectJ 1.1.1, if the body of an advice contained a reference to a
-non-statically determinable portion of `thisJoinPoint` (such as for
-example a call to `getArgs()`), then a JoinPoint object was always
-creating before entering the advice. This was the case even if the
-advice was guarded with an `if()` pointcut that evaluated to false.
-
-AspectJ 1.2 now supports the `-XlazyTjp` option that only creates the
-JoinPoint object just before dispatching to the advice body. By
-promoting the guard to a test in an `if()` pointcut, the creation of the
-JoinPoint object can be avoided altogether in the case where the test
-returns false.
-
-Consider a simple tracing aspect as follows:
-
-[source, java]
-....
-public aspect Tracing {
-
-  public static boolean enabled = false;
-
-  pointcut toBeTraced() : execution(* *(..)) || execution(new(..));
-
-  before() : toBeTraced() && if(enabled) {
-    Object[] args = thisJoinPoint.getArgs();
-    // format args and print out entry trace record etc....
-  }
-}
-....
-
-The most important consideration is the system overhead when tracing is
-turned off. Using the `-XlazyTjp` option makes the program above run
-10-100x faster, even when running a small test case with minimal GC
-issues. The optimization is disabled at join points advised by around
-advice, and an Xlint warning will be displayed in these cases.
-
-[[INCREMENTAL]]
-==== Improvements to incremental compilation.
-
-AspectJ 1.2 provides more complete incremental compilation support than
-AspectJ 1.1.1. Firstly, incremental compilation resulting from a change
-to a source file is now approximately twice as fast as it was under
-1.1.1 (even before taking the improvements to weaving time into
-account). Secondly, the incremental coverage now takes into account
-changes to resources, classes and jars on the inpath, injars, and
-aspectpath. The new `inpath` option in AspectJ 1.2 allows directories to
-be specified in addition to jars (just like a classpath) as input to the
-weaver. Any update, addition or deletion of a class file in a directory
-on the inpath will cause incremental (re)weaving.
-
-Changes to a jar file on the inpath, injars or aspectpath will now be
-detected, but will trigger a full rebuild, as will any change to the
-paths used to control compilation.
-
-[[ERROR_MESSAGES]]
-==== Improved error messages.
-
-AspectJ 1.1.1 did not provide source context information for messages
-produced during the weaving phase, even in the case where source files
-were passed to the compiler. For example, an error message arising as a
-result of a `declare error` statement might look as follows under
-AspectJ 1.1.1:
-
-[source, text]
-....
-BadClass.java:6 should not be calling bad methods
-....
-
-whereas in AspectJ 1.2 you will see:
-
-[source, text]
-....
-BadClass.java:6 error should not be calling bad methods
-new C().bad();
-^^^^^^^^^^^^^^
-     method-call(void C.bad())
-     see also: DeclareError.java:5
-....
-
-There are four new things to note about this error message. Firstly,
-errors and warnings are now prefixed with the word "error", or "warning"
-as appropriate. Secondly, the offending line of source is shown if
-source code is available. Thirdly, in the case of weaver messages
-arising as a result of `declare error` and `declare warning` statements,
-AspectJ now shows not only the location of the error or warning, but
-also the location of the `declare` statement itself. Finally, note that
-messages produced as a result of `declare error` and `declare warning`
-statements now also display the matched join point at the location of
-the error:
-
-When source code is not available, the messages show the binary input
-source (class file or jar file) in which the error or warning was
-detected:
-
-[source, text]
-....
-BadClass.java:6 error should not be calling bad methods
-(no source information available)
-       method-call(void C.bad())
-       see also: C:\...\DeclareError.java:5
-       see also: C:\...\bin-input.jar
-....
-
-This error message tells us that `BadClass.class` contained in a jar on
-the inpath called `bin-input.jar`, and originally compiled from a source
-file called `BadClass.java`, contains a join point
-(`method-call(void C.bad())` matched by a `declare error` statement on
-line 5 of the file `DeclareError.java`.
-
-[[LINT]]
-==== New lint warnings.
-
-Consider the program:
-
-[source, java]
-....
-/*01*/ class A {
-/*02*/   public void doIt() {...};
-/*03*/ }
-/*04*/
-/*05*/ class B extends A {
-/*06*/   public void doThisToo() {...};
-/*07*/ }
-/*08*/
-/*09*/
-/*10*/ public class CallsAandB {
-/*11*/
-/*12*/  public static void main(String[] args) {
-/*13*/    B b = new B();
-/*14*/    A bInDisguise = new B();
-/*15*/
-/*16*/    b.doIt();               // AspectJ 1.2 matches here
-/*17*/    bInDisguise.doIt();     // this is never matched
-/*18*/  }
-/*19*/
-/*20*/ }
-/*21*/
-/*22*/ aspect CallPCDMatchingExample {
-/*23*/
-/*24*/   before() : call(* B.doIt(..)) {
-/*25*/     System.out.println("About to call B.doIt(...)");
-/*26*/   }
-/*27*/
-/*28*/ }
-....
-
-Because the static type of `bInDisguise` is `A` (line 14), the call on
-line 17 is never matched by the pointcut expression on 24, even though
-the runtime type of `bInDisguise` is `B`. Type patterns matched in
-`call` pointcut designators are matched based on static type matching.
-Some users have found this static type matching confusing, and AspectJ
-1.2 has a new Xlint warning (`unmatchedSuperTypeInCall`) which is
-enabled by default.
-
-The compiler will now produce a warning whenever a call pointcut
-designator does not match at a join point, and a user may have expected
-it to. Compiling the above program using AspectJ 1.2 produces the
-following compiler output:
-
-[source, text]
-....
-CallsAandB.java:24 warning does not match because declaring type is A, if match desired use target(B) [Xlint:unmatchedSuperTypeInCall]
-before() : call(* B.doIt(..)) {
-           ^^^^^^^^^^^^^^^
-    see also: CallsAandB.java:17
-
-1 warning
-....
-
-The warning is telling us that the call pointcut associated with the
-before advice on line 24 of the source file does not match at a join
-point where the user may have expected it to. The source location
-corresponding to the unmatched join point is indicated by the "see also"
-line - in this case line 17 of the source file. At line 17 we find a
-call to `bInDisguise.doIt()`. Since the static type of `bInDisguise` is
-`A`, this call will never be matched. The warning also tells us a
-possible solution if we intended the pointcut to match at this join
-point: use `call(* doIt(..) && target(B)`.
-
-If you find warnings of this kind coming out when you use the AspectJ
-1.2 compiler, the recommended fix is to switch to using the `target`
-designator in place of a type pattern in the `call` pointcut expression.
-Note that there is no loss of runtime efficiency here - runtime tests
-are only added in the cases where it cannot be determined at compile
-time whether the type of the receiver will match the type specified in
-the `target` expression. Also note that `target` cannot be used in
-`declare` statements.
-
-A new Xlint warning, `needsSerialVersionUIDField` (disabled by default)
-will produce a warning at compile time if the process of weaving changes
-the default `serialVersionUID` of a serializable class, and the class
-does not define a `serialVersionUID`. By defining a `serialVersionUID`
-field, the programmer can ensure that objects serialized without the
-aspect present can be read by a version of the program in which the
-aspect is present, and vice-versa.
-
-A complimentary Xlint warning, `brokeSerialVersionCompatibility`
-(disabled by default) will produce a warning at compile time if the
-process of weaving makes an incompatible change to a serializable class
-(for example, through the addition of an inter-type declared field).
-
-[[REWEAVABLE]]
-==== The -Xreweavable option.
-
-The new `-Xreweavable` option produces class files that contain enough
-additional information in them that they can be rewoven. In time we hope
-that this can become a standard option, replacing the current
-`-Xnoweave` option. Using reweavable produces class files that can be
-legally loaded by a JVM, whereas with noweave, it is too easy to produce
-class files that will result in a verify error at runtime. The
-reweavable option makes it easy to weave code many times without having
-to decide which weave is the final one. In a future version of the
-AspectJ compiler, producing reweavable class files may become the
-default option. The trade-off at the moment is that reweavable class
-files are currently approximately twice the size of their non-reweavable
-counterparts.
-
-To ensure consistent semantics when reweaving, the AspectJ compiler
-requires that all aspects that have previously modified a class file
-during weaving be present in the system during a reweave. An error will
-be issued if any are missing.
-
-[[INPATH]]
-==== The -inpath option.
-
-The new `-inpath` option replaces the `-injars` option (which is still
-supported for backwards compatibility). It allows both directories and
-jar files to be specified using path separators to separate entries in
-the path. This option makes it easy for class files produced as the
-result of building one project to become binary input to the compilation
-of a second project.
-
-[[COMPLIANCE]]
-==== The default compliance mode of the compiler has changed from -1.3 to -1.4.
-
-The default AspectJ compiler compliance level is now 1.4 (whereas in
-previous releases the default compliance level was 1.3). This has a
-number of implications:
-
-* class files generated by the compiler are now JRE v1.2 and upwards
-compatible. (At compliance level 1.3, AspectJ generated class files that
-were compatible with JRE 1.1 also).
-* `call` pointcuts may match more join points than in the same program
-compiled at compliance level 1.3.
-
-The AspectJ compiler can be restored to 1.3 compliance settings by
-specifying the "-1.3" option on the command-line.
-
-Consider again the following example program which illustrates the
-differences in join point matching with the `call` pointcut designator
-between 1.4 and 1.3 compliance levels.
-
-[source, java]
-....
-/*01*/ class A {
-/*02*/   public void doIt() {...};
-/*03*/ }
-/*04*/
-/*05*/ class B extends A {
-/*06*/   public void doThisToo() {...};
-/*07*/ }
-/*08*/
-/*09*/
-/*10*/ public class CallsAandB {
-/*11*/
-/*12*/  public static void main(String[] args) {
-/*13*/    B b = new B();
-/*14*/    A bInDisguise = new B();
-/*15*/
-/*16*/    b.doIt();               // AspectJ 1.2 matches here
-/*17*/    bInDisguise.doIt();     // this is never matched
-/*18*/  }
-/*19*/
-/*20*/ }
-/*21*/
-/*22*/ aspect CallPCDMatchingExample {
-/*23*/
-/*24*/   before() : call(* B.doIt(..)) {
-/*25*/     System.out.println("About to call B.doIt(...)");
-/*26*/   }
-/*27*/
-/*28*/ }
-....
-
-When this program is compiled with AspectJ 1.2 using the default
-compiler options, it will produce one line of output when it is
-executed:
-
-`About to call B.doIt(...)`
-
-The same program compiled under AspectJ 1.1 (or using AspectJ 1.2 with
-the -1.3 flag specified) does not produce any output when it is run. The
-reason for the additional call pcd match is that prior to compliance
-level 1.4, Java compilers produced bytecodes that call A.doIt() (the
-defining type of the method), rather than B.doIt() (the declared type in
-the program text). The generated call to A.doIt() is not matched by the
-call pcd used in the before advice. At compliance level 1.4, the
-bytecodes retain the declared type of the receiver in the program
-source, generating a call to B.doIt(), which _is_ matched by the call
-pcd.
-
-This is a good example of why the recommended style is to use
-`call(* doIt(..)) && target(B)`, which always matches based on the
-actual type of the receiver.
-
-'''''
-
-[[AJDOC]]
-==== The ajdoc tool makes a comeback in the AspectJ 1.2 distribution.
-
-`ajdoc` (the AspectJ replacement for the `javadoc` tool) is once again
-included in the AspectJ distribution. The `ajdoc` tool produces regular
-javadoc that also shows advises and advised by relationships next to
-methods and advice. A future enhancement will show inter-type
-declarations in the target class too.
-
-*Known limitations:* Please note that `ajdoc` documents advice and
-pointcut members, shows where advice applies and links affected members
-back to the advice.  It currently does not document or add structural
-links for any inter-type declarations or other declare forms.
-
-Run the "ajdoc.bat" script just as you run javadoc.  For a list of
-accepted parameters run "ajdoc -help".  For example, to document
-everything in the Spacewar example run: +
-> cd examples +
-> ajdoc -d doc -private spacewar coordination
-
-`ajdoc` sample output for an aspect source file:
-
-image:images/ajdoc1.JPG[image]
-
-`ajdoc` sample output for advised methods:
-
-image:images/ajdoc2.JPG[image]
-
-[[LTW]]
-==== A sample script is supplied that supports load-time weaving from the command-line
-
-The AspectJ 1.2 distribution ships with sample scripts for Windows and
-Unix platforms that exploit AspectJ's binary weaving capabilities at
-application load time. You will find these scripts in the
-`doc/examples/ltw` directory of your AspectJ installation.
-
-The scripts allow you to set an environment variable, `ASPECTPATH`,
-containing a path-separator delimited list of aspect-library jar files.
-A Java application can then be launched using the "`aj`" script ("`aj`"
-is to "`ajc`" as "`java`" is to "`javac`"). If the `ASPECTPATH` is unset
-or empty, "`aj`" behaves exactly the same as "`java`", but if the
-`ASPECTPATH` contains one or more aspect libraries, the aspects in the
-library will be linked (woven) with the application code as it is
-loaded.
-
-The `doc/examples/ltw` directory of your AspectJ installation contains a
-sample application that demonstrates these capabilities. Following the
-instructions in the `README` file in that directory, running
-"`aj tracing.ExampleMain`" with `ASPECTPATH` unset produces the output:
-
-[source, text]
-....
-c1.perimeter() = 12.566370614359172
-c1.area() = 12.566370614359172
-s1.perimeter() = 4.0
-s1.area() = 1.0
-c2.distance(c1) = 4.242640687119285
-s1.distance(c1) = 2.23606797749979
-s1.toString(): Square side = 1.0 @ (1.0, 2.0)
-....
-
-If you set `ASPECTPATH` to include `../jars/tracingLib.jar`, and run
-"`aj tracing.ExampleMain`" again, the output will be:
-
-[source, text]
-....
-  --> tracing.TwoDShape(double, double)
-  <-- tracing.TwoDShape(double, double)
-  --> tracing.Circle(double, double, double)
-  <-- tracing.Circle(double, double, double)
-  --> tracing.TwoDShape(double, double)
-  <-- tracing.TwoDShape(double, double)
-  --> tracing.Circle(double, double, double)
-  <-- tracing.Circle(double, double, double)
-  --> tracing.Circle(double)
-  <-- tracing.Circle(double)
-  --> tracing.TwoDShape(double, double)
-  <-- tracing.TwoDShape(double, double)
-  --> tracing.Square(double, double, double)
-  <-- tracing.Square(double, double, double)
-  --> tracing.Square(double, double)
-  <-- tracing.Square(double, double)
-  --> double tracing.Circle.perimeter()
-  <-- double tracing.Circle.perimeter()
-c1.perimeter() = 12.566370614359172
-  --> double tracing.Circle.area()
-  <-- double tracing.Circle.area()
-c1.area() = 12.566370614359172
-  --> double tracing.Square.perimeter()
-  <-- double tracing.Square.perimeter()
-s1.perimeter() = 4.0
-  --> double tracing.Square.area()
-  <-- double tracing.Square.area()
-s1.area() = 1.0
-  --> double tracing.TwoDShape.distance(TwoDShape)
-    --> double tracing.TwoDShape.getX()
-    <-- double tracing.TwoDShape.getX()
-    --> double tracing.TwoDShape.getY()
-    <-- double tracing.TwoDShape.getY()
-  <-- double tracing.TwoDShape.distance(TwoDShape)
-  etc...
-....
-
-The scripts only support JDK 1.4 and above - attempting to use them with
-a 1.3 or lower JDK will most likely produce `NoClassDefFound` errors. We
-welcome contributions from users to improve these scripts.
-
-'''''
-
-[[SOFTEX]]
-==== SoftException now supports getCause()
-
-`org.aspectj.lang.SoftException` now supports the `getCause()` method,
-which returns the original exception wrapped by the `SoftException`.
-This means that exception chains will print correctly on 1.4 and later
-JREs.
-
-[[LTW2]]
-==== org.aspectj.weaver.tools package added
-
-A new set of public APIs are exported by the
-link:api/index.html[`org.aspectj.weaver.tools`] package that can be used
-to integrate load-time weaving into an existing class loader hierachy.
-The package implementation is included in `aspectjtools.jar`. For an
-example of how to use these APIs, see the
-`org.aspectj.weaver.WeavingURLClassLoader` implementation.
-
-'''''
-
-[[allchanges]]
-=== All changes are listed in the bug database
-
-For a complete list of changes in the 1.2 release, search for
-`target 1.2` in the bug database:
-https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Compiler&target_milestone=1.2
diff --git a/docs/dist/doc/README-121.adoc b/docs/dist/doc/README-121.adoc
deleted file mode 100644
index c51bb81df..000000000
--- a/docs/dist/doc/README-121.adoc
+++ /dev/null
@@ -1,134 +0,0 @@
-== AspectJ 1.2.1
-
-_© Copyright 2004 Contributors. All rights reserved._
-
-AspectJ 1.2.1 is largely a bug-fix release and the definition of the
-AspectJ language is unchanged from the 1.2.0 release (with the exception
-that AspectJ 1.2.1 permits the use of the '+' operator to concatenate
-the messages for declare error and warning statements). This document
-describes the tools differences between AspectJ versions 1.2 and 1.2.1.
-Users familiar with AspectJ 1.2 may find this document a quicker way to
-learn what changed in the tools.
-
-This document summarizes changes in:
-
-* Weaver messages
-* Dump support
-* JDT Compiler version
-* Line number information for join points
-* Runtime performance
-* String concatentation in declare error and warning statements
-* Load-time weaving support
-* Use of aspect libraries generated by ajc 1.2.1 with earlier versions
-of ajc
-
-See the link:changes.html[changes document] for more details, or
-xref:#allchanges[all the changes] as detailed in the bugzilla database.
-
-=== Weaver Informational Messages
-
-The AspectJ 1.2.1 compiler can produce informational messages about the
-weaving process. To see these messages, use the -showWeaveInfo compiler
-option, or set showweaveinfo=true in the iajc ant task.
-
-The following is an example of the messages produced when this option is
-enabled:
-
-[source, text]
-....
-C:\aspectj1.2.1\doc\examples\tjp>ajc -showWeaveInfo *.java
-
-Type 'tjp.Demo' (Demo.java:20) advised by around advice from 'tjp.GetInfo'
-(GetInfo.java:26) [RuntimeTest=true]
-
-Type 'tjp.Demo' (Demo.java:30) advised by around advice from 'tjp.GetInfo'
-(GetInfo.java:26) [RuntimeTest=true]
-
-Type 'tjp.Demo' (Demo.java:34) advised by around advice from 'tjp.GetInfo'
-(GetInfo.java:26) [RuntimeTest=true]
-....
-
-=== Dump Support
-
-In the event of a compiler crash, AspectJ 1.2.1 will produce a dump file
-giving important information about the state of the compiler at the time
-of the crash. These dump files should enable us to analyze problems more
-effectively. In the rare event that you witness a compiler crash, please
-attach the dump file to the bug report.
-
-In addition to producing a dump file when an abort condition is
-detected, the AspectJ 1.2.1 compiler can also be requested to create a
-dump file on detection of a compilation error. Set the property
-org.aspectj.weaver.Dump.condition=error to enable this behaviour.
-
-=== JDT Compiler Version
-
-AspectJ 1.2.1 is based on the Eclipse 3.0 final JDT compiler.
-
-=== Line Number Information for Join Points
-
-For source files compiled by ajc (as opposed to binary inputs to the
-compiler compiled with some other java compiler), ajc now emits better
-line number information for execution join points. In particular, for a
-method, constructor or advice execution join point (as matched for
-example by a declare error or declare warning statement), ajc 1.2.1
-reports the first line number of the declaration, as opposed to the line
-number of the first line of code in the body.
-
-=== Runtime Performance
-
-AspectJ 1.2.1 contains a small number of runtime performance
-optimisations, including optimisations of if(true) and if(false)
-pointcut expressions, caching of getSignature() and toString() results
-on JoinPoint objects, and an optimised implementation of cflow.
-
-In the case where there are no arguments bound in the cflow pointcut,
-programs compiled under AspectJ 1.2.1 and that make heavy use of cflow
-will run significantly faster. Thanks to the abc compiler team for
-detecting this performance related bug and for piloting the fix.
-
-=== String Concatentation in Declare Error/Warning Statements
-
-String concatentation in declare error and warning statements is now
-supported. For example, you can write:
-
-[source, java]
-....
-declare warning : jdbcCall() && !inDataLayer()
-                : "Please don't make calls to JDBC " +
-                  "outside of the data layer.";
-....
-
-=== Load-time Weaving Support
-
-The AspectJ 1.2.1 distribution contains a new jar in the lib directory,
-aspectjweaver.jar, that contains the subset of aspectjtools.jar needed
-for weaving only. This jar may be used in situations where you wish to
-exploit AspectJ's binary weaving capabilities, but do not want the full
-aspectjtools.jar around (aspectjweaver.jar is approx. 5 times smaller).
-
-In addition, the load-time weaving "aj" script which was included in the
-doc/examples/ltw directory in the 1.2 distribution has been moved into
-the regular bin directory. See xref:README-12.adoc[README-12] for
-details of using this script.
-
-=== Binary Compatibility
-
-AspectJ 1.2.1 introduces a backwards-incompatible change to the class
-file format generated by the AspectJ compiler. Classes generated by ajc
-v1.2.1 cannot be used on the inpath or aspectpath of a weaver from a
-prior version of the compiler. Classes generated by prior versions of
-the compiler can of course be placed on the inpath or aspectpath of the
-1.2.1 weaver.
-
-As ever, you should use the AspectJ runtime library (aspectjrt.jar) that
-comes with the distribution you used to build your application.
-
-'''''
-
-[[allchanges]]
-=== All changes are listed in the bug database
-
-For a complete list of changes in the 1.2.1 release, search for
-`target 1.2.1` in the bug database:
-https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&component=Compiler&target_milestone=1.2.1[https://bugs.eclipse.org/bugs/buglist.cgi?product=AspectJ&target_milestone=1.2.1&bug_status=RESOLVED&resolution=FIXED]
diff --git a/docs/dist/doc/README-150.adoc b/docs/dist/doc/README-150.adoc
deleted file mode 100644
index e3f7c1196..000000000
--- a/docs/dist/doc/README-150.adoc
+++ /dev/null
@@ -1,19 +0,0 @@
-== AspectJ 5
-
-_© Copyright 2005 Contributors. All rights reserved._
-
-AspectJ 5 introduces several important changes to the language and tools
-in order to support Java 5 and extend the capabilities of AspectJ in
-general. For language changes, see xref:../../adk15notebook/adk15notebook.adoc[AspectJ 5 Developer's Notebook]. For tools changes, see the
-link:devguide/index.html[AspectJ Development Environment Guide],
-especially the section on link:devguide/ltw.html[Load-time weaving]. The
-changes are summarized in the faq.html#q:aspectj5features[FAQ entry on
-AspectJ 5].
-
-Some of the other documentation has not been updated for AspectJ 5. For
-the latest documentation, see
-https://eclipse.org/aspectj/doc/next/index.html, linked off
-https://eclipse.org/aspectj/docs.php[the AspectJ documentation home page].
-
-For information on bug fixes in AspectJ 5 v1.5.0, see the
-link:changes.html[changes] document.
diff --git a/docs/dist/doc/README-151.adoc b/docs/dist/doc/README-151.adoc
deleted file mode 100644
index bc513d512..000000000
--- a/docs/dist/doc/README-151.adoc
+++ /dev/null
@@ -1,22 +0,0 @@
-== AspectJ 5 v1.5.1 Readme
-
-_© Copyright 2006 Contributors. All rights reserved._
-
-This release is primarily a bug fix and performance / memory usage
-release. Over 70 fixes and enhancements have been incorporated since
-1.5.0, you can see the list through
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=AspectJ&target_milestone=1.5.1&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED[this
-bugzilla query].
-
-AspectJ 1.5.1 has significantly lower memory usage than AspectJ 1.5.0,
-especially when building inside of AJDT. The improvements are also
-noticeable when batch building with Ant, or when load-time weaving.
-Batch building a project with over 1000 source files with both AspectJ
-1.5.1 and AspectJ 1.5.0 shows a 16% reduction in peak memory usage, and
-an 8% reduction in heap consumed by temporary objects. The AspectJ 1.5.1
-compiler integrated into AJDT gives memory savings of at least 50%. The
-greater savings in the AJDT environment are due to improvements in areas
-such as structure model generation that are not exercised
-
-For information on bug fixes in AspectJ 5 v1.5.1, see the
-link:changes.html[changes] document.
diff --git a/docs/dist/doc/README-152.adoc b/docs/dist/doc/README-152.adoc
deleted file mode 100644
index b903a9841..000000000
--- a/docs/dist/doc/README-152.adoc
+++ /dev/null
@@ -1,30 +0,0 @@
-== AspectJ 5 v1.5.2 Readme
-
-_© Copyright 2006 Contributors. All rights reserved._
-
-This release is primarily a bug fix release. It includes approximately
-60 fixes and enhancements that have been incorporated since the 1.5.1
-release. You can see the full list through
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&product=AspectJ&target_milestone=1.5.2&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED[this
-bugzilla query].
-
-Notable changes since the 1.5.1 release include:
-
-* https://bugs.eclipse.org/bugs/show_bug.cgi?id=126167[[_126167]] The
-handling of proceed in @Around advice has changed to be more compatible
-with code style.
-* https://bugs.eclipse.org/bugs/show_bug.cgi?id=147711[[_147711]] Members
-generated as a result of the AspectJ weaving process are now marked Java
-synthetic - enabling coverage tools such as Emma to process woven
-classes correctly.
-* https://bugs.eclipse.org/bugs/show_bug.cgi?id=138316[[_138316]] AspectJ
-has now transitioned from the CPL to the EPL license.
-* https://bugs.eclipse.org/bugs/show_bug.cgi?id=140695[[_140695]] Using a
-more optimal world for managing types when load-time weaving - reduces
-heap usage (work in progress).
-* https://bugs.eclipse.org/bugs/show_bug.cgi?id=101983[[_101983]] AspectJ
-can now support separate output folders for each input source folder -
-enables AJDT to behave more like JDT.
-
-For information on bug fixes in AspectJ 5 v1.5.2, see the
-link:changes.html[changes] document.
diff --git a/docs/dist/doc/README-153.adoc b/docs/dist/doc/README-153.adoc
deleted file mode 100644
index d5d9a228c..000000000
--- a/docs/dist/doc/README-153.adoc
+++ /dev/null
@@ -1,120 +0,0 @@
-== 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.
diff --git a/docs/dist/doc/README-154.adoc b/docs/dist/doc/README-154.adoc
deleted file mode 100644
index 7c8fa50cc..000000000
--- a/docs/dist/doc/README-154.adoc
+++ /dev/null
@@ -1,16 +0,0 @@
-== AspectJ 5 v1.5.4 Readme
-
-_© Copyright 2006 Contributors. All rights reserved._
-
-This release includes a number of bug fixes and enhancements. 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.4&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].
-
-Some key fixes include better handling of generic type declarations,
-both in regular Java classes and in combination with AspectJ constructs
-(for example, inter-type declarations)
-
- +
-
-'''''
diff --git a/docs/dist/doc/README-160.adoc b/docs/dist/doc/README-160.adoc
deleted file mode 100644
index 5e37c8efb..000000000
--- a/docs/dist/doc/README-160.adoc
+++ /dev/null
@@ -1,172 +0,0 @@
-== AspectJ 1.6.0
-
-_© Copyright 2008 Contributors. All rights reserved._
-
-=== AspectJ v1.6.0 - 23 Apr 2008
-
-For the complete list of every issue addressed since the last full
-release, see
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.0+M1&target_milestone=1.6.0+M2&target_milestone=1.6.0+RC1&target_milestone=1.6.0&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 link].
-
-Some of the highlights of 1.6.0 are:
-
-==== Upgrade to a Java 1.6 compiler
-
-AspectJ1.6.0 upgrades the internal Eclipse compiler level to version
-785_R33x - a Java 1.6 level compiler
-
-==== Better incremental compilation support in the IDE
-
-Changes under https://bugs.eclipse.org/bugs/show_bug.cgi?id=221427[bug
-221427] mean that the compiler is better able to maintain incremental
-state for projects in Eclipse and determine whether full builds or
-incremental builds are required when project dependencies change. The
-result is that the compiler will more frequently do an incremental build
-rather than falling back to doing a full build. Some basic performance
-findings can be seen in
-https://dev.eclipse.org/mhonarc/lists/aspectj-users/msg09002.html[this
-mailing list post].
-
-==== Parameter annotation matching
-
-Parameter matching is possible for constructors and methods. The use of
-parentheses around the parameter types in a method signature determine
-whether the annotations relate to the type of the parameter or the
-parameter itself.
-
-[source, java]
-....
-execution(* *(@A *));
-....
-
-- Execution of a method/ctor whose first parameter is of a type
-annotated with @A.
-
-[source, java]
-....
-execution(* *(@A (*)));
-....
-
-- Execution of a method/ctor whose first parameter is annotated with @A
-
-[source, java]
-....
-execution(* *(@A (@B *)))
-....
-
-- Execution of a method/ctor whose first parameter is annotated with @A
-and is of a type annotated with @B. Example:
-
-[source, java]
-....
-// ------ Start of Test.java -----
-@interface A {}
-@interface B {}
-
-class C {
- public void foo(@A String s) {}
- public void goo(@A @B String s) {}
-}
-
-aspect X {
- before(): execution(* *(@A (*))) {}
- before(): execution(* *(@B (*))) {}
-}
-// ------ End of Test.java -----
-....
-
-[source, text]
-....
-$ ajc -showWeaveInfo -1.6 Test.java
-Join point 'method-execution(void C.foo(java.lang.String))' in Type 'C' (A.java:5) advised by before advice from 'X' (A.java:10)
-
-Join point 'method-execution(void C.goo(java.lang.String))' in Type 'C' (A.java:6) advised by before advice from 'X' (A.java:11)
-
-Join point 'method-execution(void C.goo(java.lang.String))' in Type 'C' (A.java:6) advised by before advice from 'X' (A.java:10)
-....
-
-The first piece of advice matched both methods. The second only matched `goo()`.
-
-==== Annotation Value Matching
-
-This allows static matching of the values of an annotation - if the
-matching is done statically at weave time, it is possible to avoid some
-of the reflection that is currently required within the advice (in some
-cases). A typical use case is tracing where the trace level is defined
-by an annotation but may be switched OFF for a method if the annotation
-has a particular value. Perhaps tracing has been turned on at the type
-level and a few critical methods should not get traced. Here is some
-code showing the use case:
-
-[source, java]
-....
-enum TraceLevel { NONE, LEVEL1, LEVEL2, LEVEL3 }
-
-@interface Trace {
-  TraceLevel value() default TraceLevel.LEVEL1;
-}
-
-aspect X {
-  // Advise all methods marked @Trace except those with a tracelevel of none
-  before(): execution(@Trace !@Trace(TraceLevel.NONE) * *(..)) {
-    System.err.println("tracing "+thisJoinPoint);
-  }
-}
-
-public class ExampleOne {
-
-  public static void main(String[] args) {
-    ExampleOne eOne = new ExampleOne();
-    eOne.m001();
-    eOne.m002();
-    eOne.m003();
-    eOne.m004();
-    eOne.m005();
-    eOne.m006();
-    eOne.m007();
-  }
-
-  @Trace(TraceLevel.NONE)
-  public void m001() {}
-
-  @Trace(TraceLevel.LEVEL2)
-  public void m002() {} // gets advised
-
-  @Trace(TraceLevel.LEVEL3)
-  public void m003() {} // gets advised
-
-  @Trace(TraceLevel.NONE)
-  public void m004() {}
-
-  @Trace(TraceLevel.LEVEL2)
-  public void m005() {} // gets advised
-
-  @Trace(TraceLevel.NONE)
-  public void m006() {}
-
-  @Trace
-  public void m007() {} // gets advised
-
-}
-....
-
-Matching is currently allowed on all annotation value types *except*
-class and array. Also it is not currently supported for parameter
-annotation values.
-
-==== Changes since release candidate
-
-The only fix 1.6.0 final includes beyond the release candidate is a
-multi-threading problem in the weaver -
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=227029[bug 227029].
-
-==== Releases leading up to AspectJ 1.6.0
-
-AspectJ v1.6.0rc1- 16 Apr 2008
-
-AspectJ v1.6.0M2 - 26 Feb 2008
-
-AspectJ v1.6.0M1 - 16 Jan 2008
-
-'''''
diff --git a/docs/dist/doc/README-161.adoc b/docs/dist/doc/README-161.adoc
deleted file mode 100644
index a59e3b0bb..000000000
--- a/docs/dist/doc/README-161.adoc
+++ /dev/null
@@ -1,175 +0,0 @@
-== AspectJ 1.6.1
-
-_© Copyright 2008 Contributors. All rights reserved._
-
-The main themes of AspectJ1.6.1 are better memory usage and faster
-weaving. This has been achieved through profiling of the weaving process
-and has resulted in some serious refactoring of the weaver component
-within AspectJ. It provides exactly the same functionality as in
-previous releases, it just weaves faster now, using less code and less
-memory. This readme will give an overview of the kind of changes made
-and what can be expected when using 1.6.1 compared to previous releases.
-
-The complete list of issues resolved for AspectJ 1.6.1 can be found with
-these bugzilla queries. The first lists bugs addressed (more than 60!)
-whilst the second details enhancements made in this release.
-
-* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.1&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&bug_severity=blocker&bug_severity=critical&bug_severity=major&bug_severity=normal&bug_severity=minor&bug_severity=trivial&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=[Bugs
-resolved]
-* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.1&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&bug_severity=enhancement&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=[Enhancements
-implemented]
-
-'''''
-
-=== Refactored (https://bugs.eclipse.org/bugs/show_bug.cgi?id=231396[bug 231396])
-
-The bugzilla entry goes into more specifics on what has changed, the end
-result is that aspectjweaver.jar has had around 275 classes removed
-(about 25%) and has slimmed down by 350k (about 20%). In terms of
-performance for different scenarios:
-
-==== Straight compilation
-
-The refactoring effort has been focused on the weaver component, hence
-there is limited impact on the performance of source compilation but
-this comparison shows it is faster. Four scenarios are compared, in each
-scenario a different aspect is applied to the JDT compiler (just as a
-sample piece of source code).
-
-. 1100 source files, few aspects that target 859 join points.
-. 1100 source files, code style trace aspect targeting public methods
-(22000 join points)
-. 1100 source files, annotation style trace aspect (22000 join points)
-. 1100 source files, insane aspect (before(): within(*) \{}) (203000
-join points)
-
-image:perfSourceCompile_161.jpg[image]
-
-==== Binary weaving
-
-Moving on from source compilation to pure binary weaving, the
-improvements are more obvious. Here we are using the complete JVM
-classes jar 'rt.jar' as an example of a large jar file for weaving.
-
-. Binary weaving rt.jar (~12000 classes) with a simple aspect (1200 join
-points)
-. Binary weaving rt.jar (~12000 classes) with a code style trace aspect
-(121000 join points)
-. Binary weaving rt.jar (~12000 classes) with an annotation style trace
-aspect (121000 join points)
-. Binary weaving rt.jar (~12000 classes) with an insane aspect
-(before(): within(*) \{}) (352000 join points)
-
-image:perfBinaryWeave_161.jpg[image]
-
-==== Loadtime weaving
-
-The loadtime weaving improvements are similar to those seen for binary
-weaving (naturally). Here we are using the JDK tools jar 'tools.jar' as
-an example of a jar file for loadtime weaving.
-
-. Binary weaving tools.jar (~1900 classes) with a code style trace
-aspect
-. Binary weaving tools.jar (~1900 classes) with an insane aspect
-(before(): within(*) \{})
-
-image:perfLTW_161.jpg[image]
-
-The refactoring work has also reduced the amount of unnecessary garbage
-created on the heap during the weaving process. The next comparison
-shows roughly the reduction in amount of 'stuff' created on the heap
-during a weave. This isn't the max heap required to do a weave, it is
-just showing how many less temporary objects are allocated during an
-entire run of the weaver
-
-. First, the number of kilobytes of memory allocated from the heap
-during a weave of tools.jar with a code style trace aspect
-. Second, another run of the same thing
-. Third, this time using the insane aspect
-
-image:heapContents_161.jpg[image]
-
-So in terms of memory required, weaving the insane aspect into tools.jar
-created 1.4G of 'stuff' over the entire weaving process, compared to
-1.75G with 1.6.0.
-
-==== Loadtime weaving stress
-
-As well as addressing the memory usage of a single load time weaver, we
-have also looked at the use of load time weaving in a larger scale
-scenario, where multiple classloaders are being instantiated and
-discarded over time and each has an associated load time weaver. Under
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=210470[bug 210470] we
-looked in detail at whether the lifecycle of the weaver instance
-correctly matched the lifecycle of the associated classloader. It did
-not, but now it does! Here is a memory usage graph for AspectJ1.6.1 -
-this shows an application that spawns 7 threads which run continuously
-for a few minutes. Each thread repeatedly creates a classloader, weaves
-500 classes using it then discards the classloader. You can see that
-over time the memory is recovered correctly and when all threads
-complete (and all classloaders are orphaned), all the weavers are
-discarded.
-
-First, AspectJ 1.6.0, in which memory was never correctly recovered and
-so an OutOfMemory problem would always occur eventually.
-
-image:memLtwStress_160.jpg[image]
-
-And now AspectJ 1.6.1:
-
-image:memLtwStress_161.jpg[image]
-
-=== Incremental compilation
-
-Following on from the work done to improve compilation under Eclipse in
-AspectJ 1.6.0 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=221427[Bug
-221427] ) - we now support the building of 'broken code'
-(https://bugs.eclipse.org/bugs/show_bug.cgi?id=102733[bug 102733]). This
-is something the JDT has always been doing - where code containing
-errors continues to build (if recovery is possible) but should the
-actual methods containing the errors get invoked, an exception will be
-thrown at runtime. A number of users typically extract large projects
-from their library systems, knowing that they will only partially build
-in their current eclipse setup, but as long at they do not invoke the
-code containing the errors then they expect the rest of the project to
-run normally. AspectJ now allows this mode of operation, and it has the
-additional effect that the state of the project stays consistent, albeit
-with known errors, and this means AspectJ will more frequently do
-incremental builds rather than falling back to full builds because there
-was a compilation error.
-
-=== Language changes
-
-==== Optmized syntax for annotation value binding (https://bugs.eclipse.org/bugs/show_bug.cgi?id=234943[Bug234943])
-
-If only binding an annotation at a method-execution join point in order
-to access an *enum value* within it, there is a more optimal syntax that
-can be used to produce faster code. Given this setup:
-
-[source, java]
-....
-enum Colour { RED,GREEN,BLUE;}
-
-@interface ColouredAnnotation { Colour value(); }
-
-@ColouredAnnotation(Colour.RED)
-public void colouredMethod() { }
-....
-
-Current syntax:
-
-[source, java]
-....
-before(ColouredAnnotation anno): execution(* *(..)) && @annotation(anno) {
-  printTheColour(anno.value());
-}
-....
-
-New optional syntax:
-
-[source, java]
-....
-before(Colour col): execution(* *(..)) && @annotation(ColouredAnnotation(col)) {
-  printTheColour(col);
-}
-....
diff --git a/docs/dist/doc/README-1610.adoc b/docs/dist/doc/README-1610.adoc
deleted file mode 100644
index 5f571fce9..000000000
--- a/docs/dist/doc/README-1610.adoc
+++ /dev/null
@@ -1,50 +0,0 @@
-== AspectJ 1.6.10
-
-_© Copyright 2010 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.6.10 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.6.10;target_milestone=1.6.10M1;target_milestone=1.6.10M2;target_milestone=1.6.10RC1[here]
-
-_Release info: 1.6.10 available 17-Nov-2010_
-
-=== Changes
-
-1.6.10 is primilarily just bug fixes for AspectJ, mainly in the areas of
-ITDs and generic aspects. However, there are a couple of important
-changes that users ought to be aware of:
-
-==== AJDT Memory usage
-
-Type demotion has been in use during loadtime weaving for a while now,
-this enables the load time weavers to discard state and recover it at a
-later time (and so generally run with a smaller memory footprint). Type
-demotion is now supported under AJDT in Eclipse and will enable AJDT to
-run with smaller heaps. This feature is still experimental and needs
-turning ON if you want to try it out. To turn it on, open your AspectJ
-project properties in eclipse and in the AspectJ Compiler section,
-scroll down to 'Other' and in the non-standard compiler options setting,
-specify:
-
-[source, text]
-....
--Xset:minimalModel=true,typeDemotion=true
-....
-
-If I can get enough positive feedback about this option, it will be made
-the default. For a more detailed write up, check out the blog post:
-http://andrewclement.blogspot.com/2010/07/ajdt-memory-usage-reduction.html
-
-==== Runtime changes
-
-A big thank you to Abraham Nevado and his team who have been working on
-some issues to optimize loadtime weaving and the code generated by
-AspectJ. 1.6.10 includes some new changes to the aspectjrt.jar. The
-changes are new methods that enable the woven code to be a little
-shorter/neater. As we want to continue to have compatibility with older
-aspectjrt.jar a user needs to choose to activate these optimizations by
-specifying the option: -Xset:targetRuntime1_6_10=true. With that option
-on you will need to ensure you run against the aspectjrt.jar from a
-1.6.10 build.
-
-The changes are discussed in
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=323438[bug 323438]
diff --git a/docs/dist/doc/README-1611.adoc b/docs/dist/doc/README-1611.adoc
deleted file mode 100644
index e5f4226a2..000000000
--- a/docs/dist/doc/README-1611.adoc
+++ /dev/null
@@ -1,106 +0,0 @@
-== AspectJ 1.6.11
-
-_© Copyright 2010-2011 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.6.11 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.6.11;[here]
-
-_Release info: 1.6.11 available 15-Mar-2011_
-
-=== Notable Changes
-
-==== RC1 - Our own XML parser
-
-Due to the way AspectJ loads one of the standard XML parsers (for
-processing aop.xml) it was possible to get into a deadlock situation. To
-avoid this completely we now have our own XML parser inside for
-processing this files. It is basic but should support all the known
-syntax we have for aop files. To use it instead of the default (if you
-are encountering the deadlock) you need to specify this system property:
-org.aspectj.weaver.loadtime.configuration.lightxmlparser=true.
-
-'''''
-
-==== M2 - Multithreaded world access
-
-The weaver is backed by a representation of types called a world.
-Traditionally the worlds have supported single threads - and that is how
-they are used when doing compile time weaving or load time weaving.
-However in some configurations, e.g. pointcut matching under Spring, a
-single world instance may be getting accessed by multiple threads at the
-same time. Under
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=337855[bug337855] some
-changes have been made to better support this kind of configuration.
-
-==== M2 - various attribute deserialization issues
-
-In 1.6.9 we made some radical changes to the serialized form. It turns
-out some of the deserialization code wasn't handling these new forms
-quite right. This would manifest as an IllegalStateException or
-IndexOutOfBoundsException or similar, during attribute unpacking. These
-issues have now all been sorted out in 1.6.11.M2.
-
-==== M2 - further optimizations in model for AJDT
-
-More changes have been made for users trying out the
--Xset:minimalModel=true option to try and reduce the memory used in
-their Eclipse/AJDT configurations. This option is discussed in detail
-http://andrewclement.blogspot.com/2010/07/ajdt-memory-usage-reduction.html[here].
-It now saves even more memory. Also, previously the amount of memory it
-recovered depended on compilation order (which the user has no control
-over), but now it is insensitive to ordering and should always recover
-the same amount across builds of the same project. With a bit more
-positive feedback on this option, it will become the default under AJDT.
-
-==== M2 - spaces in path names can cause problems
-
-AspectJ had problems if the paths it was being passed (e.g. aspectpath)
-included spaces. This is bug
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=282379[282379] and has now
-been fixed.
-
-'''''
-
-==== M1 - Annotation removal
-
-Traditionally AspectJ has taken an additive approach, where
-methods/fields/supertypes/annotations can only be added to types. Now,
-chaos would likely ensue if we allowed removal of supertypes, methods,
-etc, but we are seeing an increasing number of requirements to do more
-with annotations. What kinds of thing? Basically remove existing
-annotations, or modify existing annotations by changing their values.
-1.6.11 includes a new piece of syntax that we are thinking might be
-appropriate for one of these scenarios. 1.6.11 supports this:
-
-[source, java]
-....
-declare @field: int Foo.i: -@Anno;
-....
-
-Notice the '-' in front of the annotation, meaning 'removal'. The whole
-construct means 'remove the @Anno annotation from the int field called i
-in type Foo'. It is not yet supported on the other forms of declare @.
-
-==== M1 - Intertype innertypes
-
-More work has gone into this feature. It was originally added in 1.6.9
-but the inability to use it with binary weaving greatly reduced the
-usefulness. Fixes have gone into 1.6.11 to support binary weaving. What
-do we mean by intertype innertypes? Here is an example:
-
-[source, java]
-....
-class Foo {
-  public void m() {
-    System.out.println(Inner.i);
-  }
-}
-
-aspect X {
-  public static class Foo.Inner {
-    static int i = 34;
-  }
-}
-....
-
-Only static inner types are supported.
diff --git a/docs/dist/doc/README-1612.adoc b/docs/dist/doc/README-1612.adoc
deleted file mode 100644
index ed9951d4d..000000000
--- a/docs/dist/doc/README-1612.adoc
+++ /dev/null
@@ -1,244 +0,0 @@
-== AspectJ 1.6.12
-
-_© Copyright 2010-2011 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.6.12 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.6.12;[here]
-
-_Release info:_
-
-  * _1.6.12 available 18-Oct-2011_
-  * _1.6.12.RC1 available 3-Oct-2011_
-  * _1.6.12.M2 available 18-Aug-2011_
-  * _1.6.12.M1 available 7-Jun-2011_
-
-=== Notable Changes
-
-==== RC1 - annotation value matching and !=
-
-Prior to this change it was only possible to specify an annotation match
-like this: +
- +
-get(@Anno(someValue=1) * *) || get(@Anno(someValue=3) * *) +
-
-Now it is possible to use != and write this: +
- +
-get(@Anno(someValue!=2) * *) +
-
-This can enable a group of annotated elements to be more easily
-identified. +
- +
-
-==== RC1 - More flexible pointcut/code wiring in aop.xml
-
-Prior to this version the wiring was quite limited. In order to wire a
-pointcut to a piece of code the user needed to write an abstract aspect
-that included an abstract pointcut and some advice attached to that
-abstract pointcut. Then compile this aspect and finally write the XML to
-concretize the abstract pointcut. With 1.6.12 more flexibility has been
-added and for some cases there can be no need for that abstract aspect.
-
-This is a work in progress but now you can write this in the aop.xml:
-
-[source, xml]
-....
-<concrete-aspect name="MyAspect">
-  <before pointcut="execution(* Hello.say2(..)) AND args(message)"
-   invokeClass="SomeRegularJavaClass"
-   invokeMethod="someMethod(JoinPoint tjp, java.lang.String message)"/>
-  <after pointcut="execution(* Hello.say2(..)) AND args(message)"
-   invokeClass="SomeRegularJavaClass"
-   invokeMethod="someOtherMethod(JoinPoint tjp, java.lang.String message)"/>
-</concrete-aspect>
-
-public class SomeRegularJavaClass {
-
-  public static void someMethod(org.aspectj.lang.JoinPoint tjp, String s) {
-    System.out.println("in advice4: s="+s+" at "+tjp);
-  }
-
-  public static void someOtherMethod(org.aspectj.lang.JoinPoint tjp, String s) {
-    System.out.println("in advice5: s="+s+" at "+tjp);
-  }
-}
-....
-
-In this example there is a simple regular java class containing some
-static methods. In the XML these can be joined to pointcuts, kind as if
-they were advice. Notice in the XML it specifies:
-
-* The pointcut
-* The invokeClass - the fully qualified name of the class containing the
-Java method
-* The invokeMethod - the method, including signature in the specified
-class.
-
-Due to the method specification being in XML the parameter types must be
-fully specified. The only exception to this rule is that the AspectJ
-core types JoinPoint (and JoinPoint.StaticPart) do not have to be fully
-qualified (see the example above). *Important:* notice that in the case
-above which does argument binding, the names are bound according to the
-XML specification, not according to the parameter names in the Java
-code.
-
-Around advice is also supported (the return type of the method must
-match the joinpoint return type). The example shows after advice,
-currently there is no way to specify either after returning or after
-finally, there is only after.
-
-Expanding this further would enable support for all the code style
-features in the XML. Some of the language features like declare
-annotation cannot be done in annotation style aspects but the XML
-doesn't have the same kind of restrictions. If anyone wants to help out
-by fleshing this area of the weaver out, let me know and I'll help you
-get started!
-
-'''''
-
-==== M2 - thisAspectInstance (https://bugs.eclipse.org/bugs/show_bug.cgi?id=239649[bug239649])
-
-There is now a new well known name that you can use in the if clauses in
-your aspects. thisAspectInstance provides access to the aspect instance.
-Here is an example:
-
-[source, java]
-....
-aspect X {
-  boolean doit() {
-    System.out.println("In instance check method doit()");
-    return true;
-  }
-
-  before():execution(* m(..)) && if(thisAspectInstance.doit()){
-    System.out.println(thisJoinPoint);
-  }
-}
-....
-
-Now why not just use `X.aspectOf()` instead of `thisAspectInstance`? Well,
-`thisAspectInstance` is quite useful when working with abstract/concrete
-aspects:
-
-[source, java]
-....
-abstract aspect X {
-abstract pointcut p();
-
-boolean doit() {
-    return true;
-  }
-
-  before():p()  && if(thisAspectInstance.doit()){
-    System.out.println(thisJoinPoint);
-  }
-}
-
-aspect Y extends X {
-
-  pointcut p(): execution(* m(..));
-
-}
-....
-
-Now thisAspectInstance will be an instance of the Y, not X. It enables
-the aspect instance to be used in some kind of check/guard that will
-avoid the costly creation of a thisJoinPoint object if the advice isn't
-going to run. *Note:* right now this only works for singleton aspects.
-If you have need of it with other instantiation models, please comment
-on https://bugs.eclipse.org/bugs/show_bug.cgi?id=239649
-
-==== M2 - weaving groovy
-
-Although we have been successfully weaving groovy for a long time, it is
-becoming more popular and a few issues have been uncovered when using
-non-singleton aspects with groovy code. These have been fixed.
-
-==== M2 - AJDT memory
-
-The release notes for the last few versions of AspectJ have mentioned
-two options (minimalModel and typeDemotion) which can be switched on to
-reduce memory consumption. They have had enough field testing now and
-from 1.6.12.M2 onwards they are on by default. Users should see a
-reduction in memory consumed by AspectJ projects in AJDT. It won't
-affect load time weaving. It may also help command line (or Ant) compile
-time weaving. If these options cause a problem then please raise a
-bugzilla but in the interim you could work around the problem by
-actively turning them off by specifying
--Xset:minimalModel=false,typeDemotion=false in the project properties
-for your AspectJ project.
-
-==== M2 - Java7 weaving support
-
-Some preliminary work has been done to support Java7. Java7 class files
-must contain the necessary extra verifier support attributes in order to
-load successfully on a Java7 VM - the attributes were only optional in
-Java6. It is possible to force loading of classes missing the attributes
-but that requires use of a -XX option. AspectJ 1.6.12.M2 should create
-these for you if you weave Java7 level class files. Nothing has been
-done yet to rebase AspectJ on a version of the Eclipse compiler that
-supports Java7 language constructs - that will happen after Eclipse
-3.7.1 is out.
-
-'''''
-
-==== M1 - synthetic is supported in pointcut modifiers https://bugs.eclipse.org/bugs/show_bug.cgi?id=327867[327867]
-
-It is now possible to specify synthetic in pointcuts:
-
-[source, java]
-....
-pointcut p(): execution(!synthetic * *(..));
-....
-
-==== M1 - respect protection domain when generating types during weaving https://bugs.eclipse.org/bugs/show_bug.cgi?id=328099[328099]
-
-This enables us to weave signed jars correctly. AspectJ sometimes
-generates closure classes during weaving and these must be defined with
-the same protection domain as the jar that gave rise to them. In
-1.6.12.M1 this should now work correctly.
-
-==== M1 - Suppressions inline with the JDT compiler https://bugs.eclipse.org/bugs/show_bug.cgi?id=335810[335810]
-
-Starting with Eclipse 3.6, the Eclipse compiler no longer suppresses raw
-type warnings with @SuppressWarnings("unchecked"). You need to use
-@SuppressWarnings("rawtypes") for that. AspectJ has now been updated
-with this rule too.
-
-==== M1 - Optimized annotation value binding for ints https://bugs.eclipse.org/bugs/show_bug.cgi?id=347684[347684]
-
-The optimized annotation value binding now supports ints - this is for
-use when you want to match upon the existence of an annotation but you
-don't need the annotation, you just need a value from it. This code
-snippet shows an example:
-
-[source, java]
-....
-@interface SomeAnnotation {
-  int i();
-}
-
-before(int i): execution(* *(..)) && @annotation(SomeAnnotation(i)) {
-....
-
-Binding values in this way will result in code that runs *much* faster
-than using pointcuts that bind the annotation itself then pull out the
-value.
-
-Under that same bug some changes were made to match values by name when
-binding too. Suppose the annotation had multiple int values, how would
-we select which int to bind? AspectJ will now use the name (if it can)
-to select the right value:
-
-[source, java]
-....
-@interface SomeAnnotation {
-  int mods();
-  int flags();
-}
-
-before(int flags): execution(* *(..)) && @annotation(SomeAnnotation(flags)) {
-....
-
-Here the use of 'flags' as the name of the value being bound will ensure
-the 'flags' value from any SomeAnnotation is bound and not the 'mods'
-value.
diff --git a/docs/dist/doc/README-162.adoc b/docs/dist/doc/README-162.adoc
deleted file mode 100644
index a6b88ffee..000000000
--- a/docs/dist/doc/README-162.adoc
+++ /dev/null
@@ -1,84 +0,0 @@
-== AspectJ 1.6.2
-
-_© Copyright 2008 Contributors. All rights reserved._
-
-The main theme of AspectJ1.6.2 was improved IDE incremental performance
-and a number of changes have gone in to improve how AspectJ and AJDT
-communicate - greatly reducing the time taken to perform an incremental
-compile (more details below). 1.6.2 also includes a number of fixes and
-enhancements covering areas such as:
-
-* better support for generics and intertype declarations
-* better support for annotation style syntax
-* improvements to ajdoc
-* bringing the AspectJ structure model more in line with the JDT model
-
-Many thanks to all the users that helped diagnose problems, provide
-testcases and contribute fixes. In particular:
-
-* Dave Whittaker - for generics and intertype declaration testing and
-testcases
-* Jason Naylor, Arturo Salazar - for ajdoc testcases, fixes and design
-input
-* Andrew Eisenberg - for helping shape the AJDT/AspectJ interface and
-improving incremental
-
-The complete list of issues resolved for AspectJ 1.6.2 (more than 60)
-can be found with this bugzilla query:
-
-* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.2&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=[Bugs
-resolved]
-
-'''''
-
-=== Incremental compilation (https://bugs.eclipse.org/bugs/show_bug.cgi?id=247742[bug 247742], https://bugs.eclipse.org/bugs/show_bug.cgi?id=245566[bug 245566], https://bugs.eclipse.org/bugs/show_bug.cgi?id=243376[bug 243376])
-
-Two main changes in this area.
-
-* Better communication between AJDT and AspectJ. The interface between
-the two has been modified so that AJDT can give more input to AspectJ
-about what needs to be done for an incremental compile, rather than
-having AspectJ discover it each time.
-* Structure model changes. The AspectJ structure model (of types in a
-project and the weaving amongst them) allows handles to be created for
-every node, as a lightweight reference to the elements of the model.
-These handles were similar to those that JDT uses for references to
-elements of a project but not identical. Many many fixes have gone in to
-bring the handle formats closer and closer. For example including src
-folders as elements in the AspectJ model and using the fully correct set
-of JDT delimiters throughout each handle. This means there is no longer
-an expensive transformation cost in going from an AspectJ element to its
-related JDT element and no need for AJDT to maintain a more JDT like
-version of the AspectJ structure model. The imminent development builds
-of AJDT will utilise these changes.
-
-_What difference does it make?_
-
-For every kind of build there are two numbers to take into account.
-Firstly there is the time spent in the compiler (time spent compiling
-and weaving), secondly there is the time spent in AJDT (time spent
-communicating what happened back to the user via the problems view,
-gutter annotations). Values for these times can be seen by opening the
-'AJDT Event Trace View' in eclipse. The changes within AspectJ obviously
-effect the time spent in the compiler and that is described as 'time
-spent in AJDE' within the event trace view (AJDE being the compiler
-wrapper invoked by AJDT).
-
-For a 1000 source file AspectJ project, the times spent in AJDE have
-changed as follows for a single whitespace change and save operation:
-
-* For a sourcefile unaffected by aspects. Was 1828ms, now 75ms.
-* For a sourcefile affected by some advice. Was 1844ms, now 90ms.
-* For a sourcefile affected by lots of advice. Was 1937ms, now 188ms.
-
-The AspectJ changes are done to support this, but we are still bedding
-them down in AJDT. If you want to see numbers like those above you need
-to install the latest AJDT dev builds for Eclipse 3.4 (an AJDT 1.6.1 dev
-build from the dev update site:
-https://download.eclipse.org/tools/ajdt/34/dev/update ) and then after
-starting Eclipse, select 'Window>Preferences' and in the AspectJ tab
-select 'Incremental Compiler Optimizations'. Let us know how you get on!
-When it has had enough testing it will be made the default and then is
-likely to be back ported to Eclipse 3.3 AJDT.
-
-'''''
diff --git a/docs/dist/doc/README-163.adoc b/docs/dist/doc/README-163.adoc
deleted file mode 100644
index 1609eb35f..000000000
--- a/docs/dist/doc/README-163.adoc
+++ /dev/null
@@ -1,86 +0,0 @@
-== AspectJ 1.6.3
-
-_© Copyright 2008 Contributors. All rights reserved._
-
-* xref:#split[Split matching/weaving]
-* xref:#bugsfixed[Bugs fixed]
-* xref:#notable[Notable bug fixes]
-* xref:#whatsnext[What's next?]
-
-'''''
-
-[[split]]
-=== Split matching/weaving
-
-The main goal of AspectJ 1.6.3 was to make the line between matching and
-weaving more explicit and introduce the notion of a matcher artifact.
-This matcher would enable reuse of the semantics of AspectJ pointcut
-matching without including the unnecessary code that is the weaver. Why?
-In some environments, for example Spring AOP, the weaving may be done in
-an entirely different way and the default weaver included in
-aspectjweaver.jar is just unnecessary code. Some users also find they
-have trouble getting approval for using the 'aspectjweaver.jar' in their
-projects because it includes a bytecode modification library, even when
-they are not using that code.
-
-The result of this work is documented in
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=246125[bug 246125] and
-there is now a new jar file in the distribution called
-org.aspectj.matcher.jar that includes a first pass at the matching code.
-It is not quite as slimmed down as it could be but is a first pass that
-includes no bytecode modification toolkit.
-
-To use this matcher standalone it simply requires an abstraction of some
-type system to be plugged in. The matcher code can then be used to parse
-standard pointcuts and answer questions about whether they match against
-that type system. There is no documentation on how to do this yet, as we
-don't think many users will be contributing new type systems, but
-internally we are working on an Eclipse JDT type system abstraction that
-will enable us to show matches in AJDT without actually compiling code
-(currently the two type system abstractions we ship are bytecode based
-and reflection based - both of which require compilation).
-
-'''''
-
-[[bugsfixed]]
-=== Bugs fixed
-
-The complete list of issues resolved for AspectJ 1.6.3 (more than 50)
-can be found with this bugzilla query:
-
-* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.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=[Bugs
-resolved]
-
-During 2008, there have been four AspectJ releases, fixing almost 200
-issues.
-
-'''''
-
-[[notable]]
-=== Notable bug fixes
-
-* More improvements to the way AspectJ/AJDT communicate (251277, 249216,
-258325)
-* More ajdoc improvements (256514)
-* Better support for non standard annotation style parameter ordering
-(164573, 219419)
-* Fixed long standing issue with extending Spring SecurityInterceptor
-(252722)
-* Ensure parameter annotations made on an ITD reach the target affected
-type (256669)
-
-'''''
-
-[[whatsnext]]
-=== What's next?
-
-The JDT World should be completed in the 1.6.4 timeframe and that will
-surface as benefits in AJDT, possibly leading to better LTW tooling.
-Some improved syntax for intertype declarations is a possible candidate
-feature (see discussion in
-https://dev.eclipse.org/mhonarc/lists/aspectj-users/msg10208.html[this
-mailing list thread]). A possible introduction of a code style syntax
-for the mixin style that is @DeclareParents (and a renaming of
-@DeclareParents to perhaps DeclareMixin or DeclareDelegate).
-
-'''''
diff --git a/docs/dist/doc/README-164.adoc b/docs/dist/doc/README-164.adoc
deleted file mode 100644
index dc3a71816..000000000
--- a/docs/dist/doc/README-164.adoc
+++ /dev/null
@@ -1,245 +0,0 @@
-== AspectJ 1.6.4
-
-_© Copyright 2009 Contributors. All rights reserved._
-
-* xref:#compilation[Compilation times]
-* xref:#language[Language enhancements]
-* xref:#bugsfixed[Bugs fixed]
-* xref:#whatsnext[What's next?]
-
-'''''
-
-[[compilation]]
-=== Compilation times
-
-In AspectJ 1.6.4 the goal was to improve the IDE experience, through a
-combination of improved compilation speed (both full builds and
-incremental builds), improved support for multiple-project
-configurations, and improved feedback in the editor. The following
-sections go into details on each of those topics.
-
-*Full Compilation*
-
-As an example project, all the measurements here are based on the
-modified JDT compiler that AspectJ uses internally. It is 1100 source
-files and includes aspects that affect around 850 join points. Here are
-the full build times in AJDT:
-
-AJDT 1.6.3 (uses AspectJ 1.6.3)
-
-[source, text]
-....
-21352ms
-21597ms
-21502ms
-....
-
-AJDT 1.6.5dev builds (use AspectJ 1.6.4)
-
-[source, text]
-....
-19811ms
-19802ms
-19504ms
-....
-
-About 1.5-2 seconds faster for this example.
-
-*Incremental Compilation and multi-project scenarios*
-
-In most common project configurations there are multiple eclipse
-projects in some kind of dependency hierarchy. Depending on what changes
-in a top level project, those downstream may need to be rebuilt. The
-analysis around this area has greatly improved in AspectJ 1.6.4, and
-this has resulted in much reduced incremental build times. The example
-timed here is around 20 AspectJ projects in a hierarchy, and a change is
-made to a source file in the top level project and build times are
-observed for the downstream projects.
-
-The timings reported here are accessible to anyone with AJDT installed -
-just open the 'AJDT Event Trace View' and it will report ongoing
-information about what the compiler/weaver and AJDT are up to. Be aware
-that data is only recorded in this view if it is open - so for optimal
-performance it should be shutdown, but it is useful for debugging
-scenarios or collecting basic benchmark numbers. Within the event trace
-view output, the time recorded for 'time spent in AJDE' represents the
-time spent in the compiler: analysing what has changed on the classpath,
-building code, weaving code.
-
-Initially this is using AJDT 1.6.2 (which embeds AspectJ 1.6.3):
-
-[source, text]
-....
-Type of change: adding a new method to a type
-Project build times (first one is the compile of our change, the rest are for downstream projects):
-462ms, 4ms, 145ms, 8ms, 9ms, 287ms, 471ms, 222ms, 1028ms, 143ms, 505ms, 199ms, 261ms, 1224ms,
-321ms, 704ms, 75ms, 233ms, 257ms
-Summary: Total time spent in the compiler for that change: 6558ms
----
-Type of change: whitespace change (adding just a harmless space character)
-Project build times (first one is the compile of our change, the rest are for downstream projects):
-229ms, 5ms, 10ms, 9ms, 10ms, 79ms, 43ms, 62ms, 80ms, 37ms, 64ms, 32ms, 79ms,
-154ms, 94ms, 189ms, 72ms, 144ms, 205ms
-Summary: Total time spent in the compiler for that change: 1597ms
-....
-
-Now with AspectJ 1.6.5 dev builds (which embed AspectJ 1.6.4):
-
-[source, text]
-....
-Type of change: adding a new method to a type
-Project build times (first one is the compile of our change, the rest are for downstream projects):
-288ms, 3ms, 143ms, 2ms, 2ms, 162ms, 244ms, 89ms, 489ms, 113ms, 277ms, 108ms, 143ms, 626ms,
-135ms, 260ms, 2ms, 96ms, 6ms
-Summary: Total time spent in the compiler for that change: 3188ms down from 6558ms
-
-Type of change: whitespace change (adding just a harmless space character)
-Project build times (first one is the compile of our change, the rest are for downstream projects):
-101ms, 1ms, 1ms, 1ms, 0ms, 1ms, 1ms, 1ms, 1ms, 1ms, 0ms, 1ms, 1ms, 2ms, 0ms, 1ms, 0ms, 2ms, 2ms
-Summary: Total time spent in the compiler for that change: 118ms (down from 1597ms)
-....
-
-Improvements all round, and almost instant builds now for whitespace
-changes, even in large project setups.
-
-In addition the compilation times are also improved in situations where
-AspectJ projects depend upon Java projects and where aspectpath is used.
-AJDT 1.6.5 dev builds also include some changes that really speed up
-builds.
-
-=== Better editor feedback
-
-Under https://bugs.eclipse.org/bugs/show_bug.cgi?id=246393[bug 246393]
-the problem has been addressed where sometimes spurious errors would
-appear throughout the editor for a file in AJDT when just one single
-simple syntax errors exists. More detail on this problem can be found
-http://andrewclement.blogspot.com/2009/02/aspectj-fixing-reverse-cascade-errors.html[here].
-
-'''''
-
-[[language]]
-=== Language Enhancements
-
-*Optimizing support for maintaining per join point state*
-
-The traditional way to maintain state on a per join point basis involves
-using the JoinPoint.StaticPart as a key into a map:
-
-[source, java]
-....
-aspect X pertypewithin(*) {
-  Map<JoinPoint.StaticPart,Timer> timerMap = ...
-
-  Object around(): execution(public * *(..)) {
-    Timer timerToUse = timerMap.get(thisJoinPointStaticPart);
-    timerToUse.start();
-    Object o =  proceed();
-    timerToUse.stop();
-    return o;
-  }
-}
-....
-
-These map lookups are slow. In AspectJ 1.6.4 there is a new getId()
-method on the JoinPoint.StaticPart object. The ids for all affected join
-points within a target type are unique (and start from 0) - they are
-ideal for array lookups. So using this the above aspect can be
-rewritten:
-
-[source, java]
-....
-aspect X pertypewithin(*) {
-  Timer[] timerArray = ...
-
-  Object around(): execution(public * *(..)) {
-    Timer timerToUse = timerArray[thisJoinPointStaticPart.getId()];
-    timerToUse.start();
-    Object o =  proceed();
-    timerToUse.stop();
-    return o;
-  }
-}
-....
-
-much faster. Just be aware that the ids are only unique within an
-affected target type - hence the use of pertypewithin in this example to
-ensure there is an aspect instance (and so a different array) for each
-advised type.
-
-See related https://bugs.eclipse.org/bugs/show_bug.cgi?id=89009[bug
-89009] for the full discussion
-
-=== @DeclareMixin
-
-The annotation style declare parents support (@DeclareParents) has been
-(rightly) criticized because it really does not offer an equivalent to
-what is possible with code style declare parents, it really offers a
-mixin strategy. It also has limitations such as the delegate instance
-used to satisfy any method invocations on an affected target cannot
-access the object instance for which it is acting as a delegate. To
-address these concerns a proper mixin notation has been introduced that
-makes it more clear that a mixin strategy is being employed and it
-addresses the problem of the mixin delegate accessing the affected
-target instance.
-
-The @DeclareMixin annotation is attached to a factory method which
-returns instances of the delegate. Here is a basic example:
-
-[source, java]
-....
-// The factory method that can build the delegate instance is annotated with @DeclareMixin.
-// The annotation value defines the type pattern for targets of the mixin.
-// The parameter is the object for which a delegate is being constructed.
-// The interface that will be mixed in is the return value of the factory method.
-@DeclareMixin("org.xyz..*")
-public static SomeInterface createDelegate(Object instance) {
-  return new SomeImplementation(instance);
-}
-....
-
-More examples are
-https://www.eclipse.org/aspectj/doc/released/adk15notebook/ataspectj-itds.html[here
-in the online documentation].
-
-Going forward attempts will be made to try and make @DeclareParents
-behave more like code style - if this cannot be done it is likely to be
-deprecated.
-
-'''''
-
-[[bugsfixed]]
-=== Bugs fixed
-
-The complete list of issues resolved for AspectJ 1.6.4 (more than 70)
-can be found with this bugzilla query:
-
-* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.4&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=[Bugs
-resolved]
-
-'''''
-
-[[whatsnext]]
-=== What's next?
-
-*More incremental build enhancements*
-
-A number of situations still exist where incremental compile speeds
-still needs optimizing, particular when capabilities like aspectpath or
-inpath are used.
-
-*Build state persistence*
-
-Between restarts of Eclipse the state of each project is not recorded -
-hence full builds are required upon restart. The state (and associated
-relationship model) should be persisted between restarts, but both of
-these need a review first to ensure they are not larger than they need
-to be.
-
-*Memory consumption*
-
-Both for source compilation and load-time weaving scenarios. The size of
-the model in the IDE needs reviewing, and also the type map within the
-weaver. Although the type map uses Weak/Soft references to try and
-better control how it uses memory, the JVM policies for managing these
-references vary wildly and so some work needs to be done to allow for
-these differences.
diff --git a/docs/dist/doc/README-165.adoc b/docs/dist/doc/README-165.adoc
deleted file mode 100644
index 28396df40..000000000
--- a/docs/dist/doc/README-165.adoc
+++ /dev/null
@@ -1,14 +0,0 @@
-== AspectJ 1.6.5
-
-_© Copyright 2009 Contributors. All rights reserved._
-
-[[bugsfixed]]
-=== Bugs fixed
-
-The complete list of issues resolved for AspectJ 1.6.5 can be found with
-this bugzilla query:
-
-* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.5&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=[Bugs
-resolved]
-
-'''''
diff --git a/docs/dist/doc/README-166.adoc b/docs/dist/doc/README-166.adoc
deleted file mode 100644
index 940b2cf96..000000000
--- a/docs/dist/doc/README-166.adoc
+++ /dev/null
@@ -1,64 +0,0 @@
-== AspectJ 1.6.6
-
-_© Copyright 2009 Contributors. All rights reserved._
-
-[[bugsfixed]]
-=== Bugs fixed
-
-The complete list of issues resolved for AspectJ 1.6.6 can be found with
-this bugzilla query:
-
-* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.6&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=[Bugs
-resolved]
-
-'''''
-
-=== Changes
-
-*Java5*
-
-The features of Java5 (generics, autoboxing, covariance, etc) are being
-exploited in the AspectJ codebase. This does not in any way change the
-generated code or supported source code, or the dependencies that code
-has, but it *does* mean that AspectJ requires Java5 in order to run. The
-ability to use typed collections has already flushed out a few issues
-within the codebase, improving the quality of AspectJ.
-
- +
-
-*Closing streams*
-
-Some routes through AspectJ were leaving inputstreams open and this has
-now been fixed. For example if supplying a user written configuration
-file for Lint options. Thanks to Michael Pradel for supplying patches to
-fix these issues.
-
- +
-
-*Concurrency (281654)*
-
-Fix to address a problem seen when using the weaver in a highly
-concurrent environment. Thanks to Kristian Rosenvold for the patch.
-
- +
-
-*Incremental compilation*
-
-A few fixes to problems seen only on incremental builds, problem areas
-included:
-
-* problems when fully qualifying the target type in an intertype
-declaration (269652)
-* problems when using annotation style pointcuts and reference pointcuts
-together (286341)
-
- +
-
-*JavadocRunner in NetBeans*
-
-Fixed by a patch from Joseph A. Levin - thanks!
-
- +
-
-*Various fixes/enhancements to the structure model to fix issues with
-feedback on weaving in AJDT*
diff --git a/docs/dist/doc/README-167.adoc b/docs/dist/doc/README-167.adoc
deleted file mode 100644
index 9104f2d18..000000000
--- a/docs/dist/doc/README-167.adoc
+++ /dev/null
@@ -1,180 +0,0 @@
-== AspectJ 1.6.7
-
-_© Copyright 2009 Contributors. All rights reserved._
-
-AspectJ 1.6.7 includes some radical internal changes. These improvements
-enable faster compilation, faster binary weaving, faster load time
-weaving and in some situations faster generated code.
-
-=== Pointcut timers
-
-Until 1.6.7 there has not really been a way to determine if it is just
-one of your pointcuts that is hurting your weaving performance. In 1.6.7
-it is possible to turn on timers for pointcuts. These timers show the
-time spent in the weaver matching the pointcut components against join
-points. The details on this feature are here:
-http://andrewclement.blogspot.com/2009/11/aspectj-profiling-pointcut-matching.html[Profiling
-pointcut matching]. Basically by turning on the options '-timers
--verbose' on the command line (or via Ant), output will be produced that
-looks a little like this:
-
-[source, text]
-....
-Pointcut matching cost (total=6532ms for 675000 joinpoint match calls):
-Time:482ms (jps:#168585) matching against
-    (staticinitialization(*y*.()) && persingleton(SimpleAspect))
-Time:3970ms (jps:#168585) matching against
-    (execution(* *t*.*(*)) && persingleton(SimpleAspect))
-Time:538ms (jps:#168584) matching against
-    (execution(* *f*(..)) && persingleton(SimpleAspect))
-Time:1536ms (jps:#168584) matching against
-    (execution(* java.lang.CharSequence+.*e*(..)) && persingleton(SimpleAspect))
-Time:4ms (jps:#662) matching against
-    (within(*p*) && persingleton(SimpleAspect))
-....
-
-It shows the component, the number of joinpoints (jps) the weaver
-attempted to match it against and how many milliseconds were spent
-performing those matches. The options can also be turned on
-http://contraptionsforprogramming.blogspot.com/2009/11/getting-aspectj-pointcut-matching-timer.html[]through
-AJDT. Armed with this information you can optimize your pointcuts or
-post on the mailing list asking for help. The timers can even be turned
-on for load time weaving.
-
-=== Faster matching
-
-The changes to enable pointcut profiling enabled some targeted work to
-be done on the matching algorithms. These have remained unchanged for a
-few years, but in 1.6.7 have received a bit of an overhaul. 'Fast match'
-has been implemented for the execution() pointcut, drastically reducing
-weave times for heavy users of execution - more details
-http://andrewclement.blogspot.com/2009/11/aspectj-how-much-faster-is-aspectj-167.html[here].
-The pointcut cost calculator (which is used to sort pointcuts to
-optimize matching speed) has been reviewed and after determining that
-this() ought to be considered cheaper than call() - any user combining
-those two pointcut designators should see an improvement (one users
-build time reduced from 38minutes to 6minutes with that change!).
-
-As well as faster matching there is also less exploration to determine a
-match. Visitors that walk hierarchies and discover methods now terminate
-as early as possible once they can determine something is a match or is
-definetly not a match. This reduces memory usage, speeds up weaving and
-reduces the occurrences of those annoying 'cantFindType' messages.
-
-=== aop.xml processing
-
-The processing of include/exclude entries in aop.xml has been rewritten.
-It now optimizes for many more common patterns. If a pattern is
-optimized then there is no need to ask the weaver to do an expensive
-include/exclude match. More details
-http://andrewclement.blogspot.com/2009/12/aspectj-167-and-faster-load-time.html[here].
-
-=== Less need to tweak options for load time weaving
-
-A number of options were previously configurable for load time weaving
-that were considered experimental. These options have now been tested
-enough in the field that they are considered fully reliable and are on
-by default in 1.6.7. If you have been using either of these:
-
-* typeDemotion
-* runMinimalMemory
-
-then please delete them from your weaver options section, the weaver
-will now do the right thing out of the box.
-
-=== Benchmarking memory and performance
-
-All those changes above, and some additional tweaks, mean we are now
-using less memory than ever before and getting things done more quickly.
-
-http://andrewclement.blogspot.com/2009/12/aspectj-167-and-faster-load-time.html[This
-post] discusses the details. From that article, the graph below shows
-the speed and memory consumption of the various AspectJ 1.6 releases
-when load time weaving a small application loading in Tomcat. For each
-of 10 iterations (x axis), the top comparison is startup time in
-milliseconds, the lower comparison is memory used in bytes.
-
-image:167Memory.png[image]
-
-=== Annotation binding
-
-All those changes affect compilation/weaving but what about the code
-that actually runs? One user, Oliver Hoff, raised a query on the
-performance of annotation binding. His case uncovered an old TODO left
-in the code a few years ago:
-
-[source, text]
-....
-// OPTIMIZE cache result of getDeclaredMethod and getAnnotation?
-....
-
-Annotation binding has become a very common use case since that was
-written and 1.6.7 was the time TODO it.
-
-The result is an optimization for the general case of binding an
-annotation, but also support for a new bit of syntax that aids binding
-of a string annotation member value - using this latter syntax generates
-extremely fast code.
-
-Here are some numbers for a simple benchmark retrieving the annotation
-value at an execution join point in different ways. The three scenarios
-look like this (where the annotation type is 'Marker' and it has a
-String value field called 'message'):
-
-[source, java]
-....
-// CaseOne: annotation value fetching is done in the advice:
-pointcut adviceRetrievesAnnotation(): execution(@Marker * runOne(..));
-before(): adviceRetrievesAnnotation() {
-  Marker marker = (Marker) ((MethodSignature)
-      thisJoinPointStaticPart.getSignature()).getMethod().getAnnotation(Marker.class);
-  String s = marker.message();
-}
-
-// CaseTwo: annotation binding is done in the pointcut, advice retrieves message
-pointcut pointcutBindsAnnotation(Marker l): execution(@Marker * runTwo(..)) && @annotation(l);
-before(Marker l): pointcutBindsAnnotation(l) {
-  String s = l.message();
-}
-
-// CaseThree: annotation binding directly targets the message value in the annotation
-pointcut pointcutBindsAnnotationValue(String msg):
-  execution(@Marker * runThree(..)) && @annotation(Marker(msg));
-before(String s): pointcutBindsAnnotationValue(s) {
-  // already got the string
-}
-....
-
-Before 1.6.7, case 2 was slower than case 1 and case 3 wasn't supported
-syntax. The two bugs with more info are
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=296484[Bug 296484] and
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=296501[Bug 296501].
-
-Now this is a micro benchmark, slightly unrepresentative of the real
-world because the advice isn't doing anything else, but it does really
-stress the AspectJ binding code. For the benchmark numbers the join
-points advised by those advice were invoked 1,000,000 times. AspectJ
-1.6.7:
-
-[source, text]
-....
-Manually fetching annotation with getAnnotation(): 645ms
-Binding annotation with @annotation(Marker): 445ms  (was >20 *seconds* for 1.6.6, due to an extra reflection call)
-Binding annotation value with @annotation(Marker(message)): 3ms
-....
-
-The new syntax is definetly the best way to bind an annotation string
-value.
-
-'''''
-
-[[bugsfixed]]
-==== Bugs fixed
-
-The complete list of issues resolved for AspectJ 1.6.7 can be found with
-this bugzilla query:
-
-* https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&product=AspectJ&target_milestone=1.6.7&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=[Bugs
-resolved]
-
-'''''
diff --git a/docs/dist/doc/README-168.adoc b/docs/dist/doc/README-168.adoc
deleted file mode 100644
index 0adbd557a..000000000
--- a/docs/dist/doc/README-168.adoc
+++ /dev/null
@@ -1,87 +0,0 @@
-== AspectJ 1.6.8
-
-_© Copyright 2009 Contributors. All rights reserved._
-
-The first sentence in the 1.6.7 readme was 'AspectJ 1.6.7 includes some
-radical internal changes.'
-
-Unfortunately not enough testing was done on 1.6.7 and two nasty issues
-were found that really needed addressing. Fixes for these issues are all
-that is new in 1.6.8.
-
-=== Incorrect treatment of some aop.xml include/exclude patterns
-
-See https://bugs.eclipse.org/bugs/show_bug.cgi?id=298786[Bug 298786]
-
-Basically, if a certain combination of includes and excludes were
-specified in the within section, then the weaver would fail to merge
-them correctly. The conditions for the failure are:
-
-* you need an exclude pattern that the weaver is not optimizing for
-(basically a pattern that could not be matched based upon the typename
-alone, eg. based on whether the type has an annotation)
-* you need two include patterns - one that is being optimized and one
-that is not
-
-These three meet that spec:
-
-[source, xml]
-....
-<include within="*"/>
-<include within="@Foo *"/>
-<exclude within="*Funk*y*"/>
-....
-
-The include="*" can be optimized. The include="@Foo *" is not optimized.
-The exclude="*Funk*y*" is not optimized (this one could be but isn't
-right now as it includes multiple wildcards).
-
-With that configuration any types that the include="*" would have
-accepted are not accepted.
-
-=== Stack overflow problem in ReferenceType.isAssignableFrom()
-
-See https://bugs.eclipse.org/bugs/show_bug.cgi?id=298908[Bug 298908]
-
-This is actually a problem AspectJ has had for a long time, but has
-always proved elusive to recreate. It turns out that it is memory
-related and the more aggressive policy in 1.6.7 causes it to occur much
-more frequently.
-
-The stack trace when this is hit looks like:
-
-[source, text]
-....
-...
-at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
-at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
-at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
-at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
-at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
-at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
-at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
-at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
-at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
-at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:427)
-at org.aspectj.weaver.ReferenceType.isAssignableFrom(ReferenceType.java:393)
-...
-....
-
-The weaver has changed over the 1.5 and 1.6 releases and is now reaching
-a point where it really shrinks quite small when not in use (maybe in a
-loadtime environment you have finished loading all your classes). The
-aim is that it can rebuild any required state that is needed later. With
-the move in 1.6.7 from Soft to Weak references, things are being
-discarded much sooner and this is exercising the state rebuilding code
-that wasn't used that often prior to 1.6.7.
-
-The problem is actually because the call on a generic type to get the
-raw type was actually broken and returning the generic type. This then
-loops forever trying to get the raw type from the generic type. This
-happens because the world should store only raw types (which point to
-their generic form) but there was a bug in state rebuilding that instead
-put the generic type directly in the world.
-
-'''''
-
-Thanks to everyone who helped get to the bottom of these problems.
diff --git a/docs/dist/doc/README-169.adoc b/docs/dist/doc/README-169.adoc
deleted file mode 100644
index 943cc6d90..000000000
--- a/docs/dist/doc/README-169.adoc
+++ /dev/null
@@ -1,294 +0,0 @@
-== AspectJ 1.6.9
-
-_© Copyright 2010 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.6.9 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.6.9;target_milestone=1.6.9M1;target_milestone=1.6.9M2;target_milestone=1.6.9RC1[here]
-
-=== Features
-
-==== declare annotation supports compound signature patterns: https://bugs.eclipse.org/bugs/show_bug.cgi?id=287613[287613]
-
-Until now it wasn't possible to express a compound pattern in any of the
-declare annotation constructs that take a member signature. For example,
-if you wanted to attach an annotation to all your getter like methods,
-you needed two constructs
-
-[source, java]
-....
-declare @method: * is*(): @FooBar;
-declare @method: * get*(): @FooBar;
-....
-
-Now AspectJ allows compound patterns for declare
-@method/@constructor/@field.
-
-[source, java]
-....
-declare @method: (* is*()) || (* get*()): @FooBar;
-....
-
-==== Intertype declaration of member types
-
-It is now possible to ITD member types. The syntax is as would be
-expected. This example introduces a new member type called Inner into
-type Foo:
-
-[source, java]
-....
-public class Foo {
-    public static void main(String[] args) {
-        new Inner().run();
-    }
-}
-
-aspect Magic {
-    public static class Foo.Inner {
-        public void run() {
-            System.out.println("Inner.run() executing");
-        }
-    }
-}
-....
-
-Only static member types are supported.
-
-==== 'Optional' aspects: https://bugs.eclipse.org/bugs/show_bug.cgi?id=310506[310506]
-
-It is not uncommon to ship a library aspect separately to a jar upon
-which it depends. In the case of Spring there is an aspect library
-containing a multitude of aspects that attach different technologies
-(transactions/persistence/etc) to your application. Normally an aspect
-will fail with a "can't find type" style message if a weaver is told to
-use it and yet it references some missing dependency. This can be
-annoying and require you to include jars on your classpath (or in your
-maven configuration) that you don't actually use, they are *only* there
-to avoid problems with the aspect. In 1.6.9 you can add a setting to
-these aspects in the aop.xml that makes them optional. The setting
-mentions a type and if that type cannot be found the aspect immediately
-shuts itself down. This basically means that the aspect is only going to
-do its job if the type being mentioned in the setting is around. This
-enables the aspect library to be on the aspect path but any aspects
-within it to switch-off if there is nothing for them to do.
-
-Here is an example, 'AspectA' will switch itself off if the type
-'a.b.c.Anno' cannot be found:
-
-[source, xml]
-....
-<aspect name="AspectA" requires="a.b.c.Anno"/>
-....
-
-==== Reduction in class file sizes: https://bugs.eclipse.org/bugs/show_bug.cgi?id=312839[312839]
-
-More details here:
-http://andrewclement.blogspot.com/2010/05/aspectj-size-is-important.html
-but basically some work has been done to improve the serialized form of
-aspects. As an example, a compiled Roo petclinic sample (which uses lots
-of aspects and ITDs) is down from 1Meg (AspectJ 1.6.9m2) to 630k
-(AspectJ 1.6.9rc1).
-
-==== Transparent weaving: https://bugs.eclipse.org/bugs/show_bug.cgi?id=309743[309743]
-
-In a further step towards transparent weaving, support for the AjType
-reflection system is now being made optional. This means if intending to
-use the AjTypeSystem to reflect on woven code, then the code must be
-built with the option -makeAjReflectable. This change is being made
-because the reflection supporting metadata that enables the AjTypeSystem
-to work can break other tools that are just using regular reflection on
-the classes. These days many more users are processing classes using
-standard reflection than are using AjTypeSystem. The related bugzilla
-discussing this issue is
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=309743[309743].
-
-==== Overweaving: https://bugs.eclipse.org/bugs/show_bug.cgi?id=293450[293450]
-
-Preliminary support for overweaving was added in AspectJ 1.6.7, but now
-in AspectJ 1.6.9m2 it is much more reliable. Basically it is an
-alternative to reweaving when needing to weave a class multiple times.
-Overweaving can cope with 'other tools' modifying the bytecode in
-between AspectJ weaves, whereas reweaving cannot. More details are in
-the related bugzilla
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=293450[293450] and in this
-http://andrewclement.blogspot.com/2010/05/aspectj-overweaving.html[blog
-article]. A weaver is switched into overweaving mode by the option
--Xset:overWeaving=true - which can be specified on the command line or
-in the weaver options section of aop.xml. There is still more work to be
-done on this feature - any feedback is welcome.
-
-==== AOP Scoping: https://bugs.eclipse.org/bugs/show_bug.cgi?id=124460[124460]
-
-Another feature that had preliminary support a while ago is aspect
-scoping in aop.xml. This has also been improved in AspectJ1.6.9m2. For
-those not aware of it, it is the ability to specify a scope against
-aspects defined in your loadtime weaving aop.xml file. A scope
-effectively enables the user to limit the applicability of your aspect
-to some subset of all those types included by the weaver include
-section. Why is it needed? It can be useful when taking an aspect that
-did not originally scope itself properly (using a within clause) and
-needing to limit its effect in a load time weaving context. Think of it
-as a within pattern that you can put into the aop.xml that augments all
-the pointcuts defined in the original aspect.
-
-Here is an example:
-
-[source, xml]
-....
-<aspectj>
-  <aspects>
-    <aspect name="X"/>
-    <aspect name="Y" scope="com.foo..*"/>
-  </aspects>
-  <weaver>
-    <include within="com..*"/>
-  </weaver>
-</aspectj>
-....
-
-In this example the weaver include section specifies all the types in
-com..* should be woven and the aspects to be used are X and Y. The new
-'scope' setting on aspect Y's definition allows finer control, and
-specifies that Y should in fact only be applied to com.foo..* types.
-
-==== Message inserts for declare warning/error messages
-
-It is now possible to use joinpoint context in the messages attached to
-declare warning and declare error constructs. Some examples:
-
-[source, java]
-....
-declare warning: execution(* A.m(..)): "joinpoint is {joinpoint}";
-declare warning: execution(* A.m(..)): "joinpoint kind is '{joinpoint.kind}'";
-declare warning: get(int *) && within(A): "joinpoint signature is {joinpoint.signature}";
-declare warning: execution(* A.m(..)): "joinpoint declaring type is {joinpoint.signature.declaringType}";
-declare warning: execution(* A.m(..)): "signature name for method is {joinpoint.signature.name}";
-declare warning: execution(* A.m(..)): "joinpoint location is {joinpoint.sourcelocation.sourcefile}:{joinpoint.sourcelocation.line}";
-declare warning: execution(* A.m(..)): "joinpoint line is '{joinpoint.sourcelocation.line}'";
-
-declare warning: get(int *): "warning is from aspect {advice.aspecttype}";
-declare warning: execution(* A.m(..)): "warning sourcelocation is {advice.sourcelocation.sourcefile}:{advice.sourcelocation.line}";
-....
-
-The syntax is to enclose the relevant key within curly brackets within
-the message. Please raise an enhancement request if you need other keys
-- the set supported so far are all those shown in the example above.
-
-==== declare warning/error for type patterns
-
-It is now possible to use a type pattern with declare warning and
-declare error. For example:
-
-[source, java]
-....
-declare warning: I+ && !hasfield(int i): "Implementations of I are expected to have a int field called i";
-....
-
-==== Type category type patterns
-
-This is the ability to narrow the types of interest so that interfaces
-can be ignored, or inner types, or classes or aspects. There is now a
-new is() construct that enables this:
-
-[source, java]
-....
-execution(* (!is(InnerType)).m(..)) {}
-!within(* && is(InnerType)) {}
-....
-
-Options for use in is() are: ClassType, AspectType, InterfaceType,
-InnerType, AnonymousType, EnumType, AnonymousType.
-
-Note: It is important to understand that "!within(is(InnerType))" and
-"within(!is(InnerType))" are not the same. The latter one is unlikely to
-be what you want to use. For example here:
-
-[source, java]
-....
-class Boo {
-  void foo() {}
-  class Bar {
-    void foo() {}
-  }
-}
-....
-
-Bar.foo() will match within(!is(InnerType)) because within considers all
-surrounding types (so although Bar doesn't match the pattern, the
-surrounding Boo will match it). Bar.foo() will not match
-!within(is(InnerType)) because Bar will match the pattern and then the
-result of that match will be negated.
-
-==== Intertype fields preserve visibility and name
-
-Some users always expect this:
-
-[source, java]
-....
-class C {
-}
-
-aspect X {
-  private int C.someField;
-}
-....
-
-To cause a private field called 'someField' to be added to C. This is
-conceptually what happens during compilation but if any user then later
-attempts to access someField via reflection or runs a javap against the
-class file, they will see that isn't what happens in practice. A public
-member is added with a mangled name. For code attempting to access
-someField built with ajc, the visibility of the declaration will, of
-course, be respected. But for frameworks accessing the code later
-(typically through reflection), it can cause confusion. With AspectJ
-1.6.9 the name and visibility are now preserved. Compile time semantics
-remain the same, it is only the weaving process that has changed to
-produce slightly different output.
-
-Here is the output of javap when that is built with 1.6.8:
-
-[source, java]
-....
-class C extends java.lang.Object{
-    public int ajc$interField$X$someField;
-    C();
-}
-....
-
-Here is the output of javap when that is built with 1.6.9:
-
-[source, java]
-....
-class C extends java.lang.Object{
-    private int someField;
-    C();
-    public static int ajc$get$someField(C);
-    public static void ajc$set$someField(C, int);
-}
-....
-
-The name 'someField' is preserved. The visibility is also preserved but
-because of that we also need to generate some accessors to get at the
-field.
-
-==== AspectJ snapshots in a maven repo
-
-To ease how AspectJ development builds can be consumed, they are now
-placed into a maven repo. When a new version of AspectJ is put into AJDT
-it is also put into the maven.springframework.org repo. The maven
-compatible repo is `maven.springframework.org/snapshot/org/aspectj` -
-and if you browse to it you will see it currently contains 1.6.9 dev
-builds under the name 1.6.9.BUILD-SNAPSHOT. The repo is added with this
-magic:
-
-[source, xml]
-....
-<repository>
-    <id>maven.springframework.org</id>
-    <name>SpringSource snapshots</name>
-    <url>http://maven.springframework.org/snapshot</url>
-</repository>
-....
-
-and then the version to depend upon is: 1.6.9.BUILD-SNAPSHOT
-
-'''''
diff --git a/docs/dist/doc/README-170.adoc b/docs/dist/doc/README-170.adoc
deleted file mode 100644
index 2437d10ef..000000000
--- a/docs/dist/doc/README-170.adoc
+++ /dev/null
@@ -1,125 +0,0 @@
-== AspectJ 1.7.0
-
-_© Copyright 2011 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.7.0 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.0;[here]
-
-_Release info:_
-
-* _1.7.0 available 2-Jul-2012_
-* _1.7.0.RC1 available 25-May-2012_
-* _1.7.0.M1 available 16-Dec-2011_
-
-=== Notable Changes
-
-==== Java 7 bytecode weaving
-
-The first milestone of 1.7.0 upgraded the compiler but this still left
-the weaver with some issues if it had to weave into bytecode containing
-some of the new features that were allowed by Java 1.7. In particular
-this meant any bytecode containing the INVOKEDYNAMIC (new instruction
-for 1.7) and the related new constant pool entry types that support it.
-RC1 now supports weaving into bytecode containing these features.
-However, the new INVOKEDYNAMIC instruction does not surface as a join
-point yet so you cannot write a pointcut to match on it. If you use
-execution() pointcuts as opposed to call() then you will still be able
-to advise what the invokedynamic actually calls.
-
-==== Bytecode caching for loadtime weaving
-
-Under https://bugs.eclipse.org/bugs/show_bug.cgi?id=367673[bug 367673]
-we have had a contribution (thanks John Kew!) that enables a bytecode
-cache for loadtime weaving. The details and some rudimentary benchmark
-numbers are in the bug. Basically it caches woven bytecode on first
-start of a system using LTW and then reuses that woven bytecode on
-subsequent starts - this saves weaving time and also memory consumption.
-To activate it, use the following system properties:
-
-[source, text]
-....
--Daj.weaving.cache.enabled=true
--Daj.weaving.cache.dir=/tmp/aspectj-cache/
-....
-
-==== Upgrade to Java 7
-
-For AspectJ 1.7.0, AspectJ moved from Eclipse JDT Core 0.785_R33x
-(Eclipse 3.3) to Eclipse JDT Core 0.B79_R37x (Eclipse 3.7). This is a
-big change where AspectJ is picking up four years of change from the
-Eclipse compiler.
-
-It means that you can now use the new Java 7 language constructs in your
-programs:
-
-- Diamond operator in advice:
-
-[source, java]
-....
-aspect Foo {
-  before(): execution(* *(..)) {
-    List ls = new ArrayList<>();
-  }
-}
-....
-
-- Diamond operator in ITD:
-
-[source, java]
-....
-public List DiamondITD.ls = new ArrayList<>();
-....
-
-- Underscore literals and binary literals in advice:
-
-[source, java]
-....
-before(): execution(* *(..)) {
-  int onemill = 1_000_000;
-  int four =0b100;
-}
-....
-
-- Multi-catch:``
-
-[source, java]
-....
-before(): execution(* main(..)) {
-  try {
-    foo("abc");
-  } catch (ExceptionA | ExceptionB ex) {
-    bar(ex);
-  }
-}
-....
-
-- String switch:``
-
-[source, java]
-....
-before(String s): execution(* *(..)) && args(s) {
-  switch(s) {
-    case "quux":
-      foo();
-      break;
-    case "bar":
-      foo();
-      break;
-    default:
-      foo();
-      break;
-  }
-}
-....
-
-- Try with resources:``
-
-[source, java]
-....
-try (
-  InputStream in = new FileInputStream(src);
-  OutputStream out = new FileOutputStream(dest))
-{
-  // code
-}
-....
diff --git a/docs/dist/doc/README-171.adoc b/docs/dist/doc/README-171.adoc
deleted file mode 100644
index 30515f0e2..000000000
--- a/docs/dist/doc/README-171.adoc
+++ /dev/null
@@ -1,34 +0,0 @@
-== AspectJ 1.7.1
-
-_© Copyright 2011 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.7.1 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.1;[here]
-
-_Release info: 1.7.1 available 6-Sep-2012_
-
-=== Changes
-
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=388971[388971] Double
-Synthetic attributes on some around advice members +
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=387718[387718]
-RuntimeException when trying to compile broken code +
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=387568[387568] Warning
-"Xlint:unresolvableMember" for enums +
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=387444[387444] Softening
-exception in try-with-resources +
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=386888[386888] spring-data
-hello-worlds sample fails to compile with 1.7.0 +
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=386337[386337] Light AOP
-Parser does not support declare-annotation +
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=386049[386049] Error "must
-implement abstract inter-type declaration" even though build is fine +
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=384401[384401] NPE when no
-pointcut in afterthrowing annotation style advice +
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=384398[384398] Type
-Mismatch error when using inner classes contained in generic types
-within ITDs +
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=381906[381906] ASPECTJ
-Internal Compiler Error +
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=73507[73507] Public ITD of
-fields on interfaces creates mangled members +
diff --git a/docs/dist/doc/README-172.adoc b/docs/dist/doc/README-172.adoc
deleted file mode 100644
index 52754ad8e..000000000
--- a/docs/dist/doc/README-172.adoc
+++ /dev/null
@@ -1,23 +0,0 @@
-== AspectJ 1.7.2
-
-_© Copyright 2011 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.7.2 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.2;[here]
-
-_Release info: 1.7.2 available 13-Feb-2013_
-
-=== Fixes:
-
-* Incorrect signature attributes generated into some class files for
-complex generics declarations.
-* Generics information incorrectly being placed in the stackmap
-verification attributes.
-* Problems with generic ITDs not being picked up correctly, resulting in
-'method must be implemented' errors.
-* Problems with multiple usages of 'requires' clause in aop.xml for
-conditional aspects.
-* Generated if() pointcut representations in class files change on only
-a source whitespace change.
-* Intermittent problem with generic ITDs due to weak references being
-collected too soon.
diff --git a/docs/dist/doc/README-173.adoc b/docs/dist/doc/README-173.adoc
deleted file mode 100644
index 73a0ad320..000000000
--- a/docs/dist/doc/README-173.adoc
+++ /dev/null
@@ -1,8 +0,0 @@
-== AspectJ 1.7.3
-
-_© Copyright 2011 Contributors. All rights reserved._
-
-_Release info: 1.7.3 available 13-Jun-2013_
-
-The list of resolved issues in 1.7.3 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.3;[here]
diff --git a/docs/dist/doc/README-174.adoc b/docs/dist/doc/README-174.adoc
deleted file mode 100644
index 20464744a..000000000
--- a/docs/dist/doc/README-174.adoc
+++ /dev/null
@@ -1,34 +0,0 @@
-== AspectJ 1.7.4
-
-_© Copyright 2013 Contributors. All rights reserved._
-
-The list of resolved issues in 1.7.4 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.7.4;[here]
-
-_Release info: 1.7.4 available 24-Oct-2013_
-
-*Notes*
-
-* This release includes an important fix for using loadtime weaving in a
-JVM where JMX is turned on
-(https://bugs.eclipse.org/bugs/show_bug.cgi?id=415266[415266])
-* There are some new message insert keys usable in declare error/warning
-(https://bugs.eclipse.org/bugs/show_bug.cgi?id=420210[420210]) The new
-keys are:
-+
-[source, java]
-....
-joinpoint.enclosingclass // Bar
-joinpoint.enclosingmember // void Bar.foo(String)
-joinpoint.enclosingmember.name // foo
-....
-+
-All keys are case insensitive.
-* It is now possible to specify individual xlint settings without
-needing to supply a file
-(https://bugs.eclipse.org/bugs/show_bug.cgi?id=419279[419279])
-+
-[source, text]
-....
-ajc -Xlint:adviceDidNotMatch=error,noGuardForLazyTjp=ignore Foo.java
-....
diff --git a/docs/dist/doc/README-180.adoc b/docs/dist/doc/README-180.adoc
deleted file mode 100644
index 9a2ba78be..000000000
--- a/docs/dist/doc/README-180.adoc
+++ /dev/null
@@ -1,72 +0,0 @@
-== AspectJ 1.8.0
-
-_© Copyright 2014 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.8.0 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.0.M1;target_milestone=1.8.0;[here]
-
-_Release info:_
-
-* _1.8.0 available 17-Apr-2014_
-* _1.8.0.RC1 available 18-Mar-2014_
-* _1.8.0.M1 available 29-Jul-2013_
-
-=== Notable changes
-
-==== Java 8 compilation
-
-AspectJ has been updated to the latest available Eclipse Java compiler
-version that compiles Java8 code (the version available as a feature
-patch on top of Eclipse 4.3.2).
-
-Here is a sample AspectJ8 program:
-
-[source, java]
-....
-// === 8< ==== C.java ==== 8< ===
-import java.util.Arrays;
-
-interface I {
-    // Default method
-    default void foo() {
-        System.out.println("ABC");
-    }
-}
-
-public class C implements I{
-    public static void main(String[] args) {
-        new C().foo();
-        // Lambda
-        Runnable r = () -> { System.out.println("hello world!"); };
-        r.run();
-        // Used Java8 b97
-        Arrays.asList(MyClass.doSomething()).forEach((p) -> System.out.println(p));
-    }
-}
-
-aspect X {
-    before(): execution(* I.foo()) {
-        System.out.println("I.foo running");
-    }
-    before(): staticinitialization(!X) {
-        System.out.println("Clazz "+thisJoinPointStaticPart);
-    }
-}
-
-
-class Utils {
-    public static int compareByLength(String in, String out) {
-        return in.length() - out.length();
-    }
-}
-
-class MyClass {
-    public static String[] doSomething() {
-        String []args = new String[]{"4444","333","22","1"};
-        // Method reference
-        Arrays.sort(args,Utils::compareByLength);
-        return args;
-    }
-}
-// === 8< ==== C.java ==== 8< ===
-....
diff --git a/docs/dist/doc/README-181.adoc b/docs/dist/doc/README-181.adoc
deleted file mode 100644
index ef0e8a1ee..000000000
--- a/docs/dist/doc/README-181.adoc
+++ /dev/null
@@ -1,16 +0,0 @@
-== AspectJ 1.8.1
-
-_© Copyright 2014 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.8.1 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.1;[here]
-
-_Release info: 1.8.1 available 20-Jun-2014_
-
-=== Notable changes
-
-==== Java 8 update
-
-As Eclipse itself nears the 4.4 release, AspectJ has been updated to the
-latest Eclipse JDT Core that will be included in it, picking up numerous
-Java8 related fixes.
diff --git a/docs/dist/doc/README-1810.adoc b/docs/dist/doc/README-1810.adoc
deleted file mode 100644
index cce5da187..000000000
--- a/docs/dist/doc/README-1810.adoc
+++ /dev/null
@@ -1,37 +0,0 @@
-== AspectJ 1.8.10
-
-_© Copyright 2016 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.8.10 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.10;[here]
-
-_Release info: 1.8.10 available 9-Dec-2016_
-
-=== Notable changes
-
-==== JDT Upgrade
-
-The JDT compiler inside AspectJ has been upgraded to the Eclipse Neon.2
-level (JDT commit #75dbfad0).
-
-==== Java8
-
-The Eclipse JDT compiler embedded inside AspectJ now requires Java 8, so
-that is the minimum required level to compile sources with AspectJ.
-However, if only doing weaving and no compilation then it is possible to
-use Java 7.
-
-==== Annotation style around advice and proceed (https://bugs.eclipse.org/bugs/show_bug.cgi?id=500035[Bug 500035])
-
-A long standing issue that has been lurking in the handling of arguments
-passed to proceed for annotation style aspects has been fixed. If, at a
-joinpoint where 'this'/'target' differ (for example at some call
-joinpoints), the pointcut bound either 'this' or 'target' (but not
-both), then the system would still expect the advice to pass both 'this'
-and 'target' into the proceed call. With the fix here you only need to
-pass what you bind. So if you bind only 'this' you don't need to pass
-'target' (and vice versa). This will affect users that have been working
-around this quirk by passing both 'this' and 'target'. That isn't
-necessary anymore. This fix is in aspectjrt.jar so you will need to be
-using the 1.8.10 version of aspectjrt.jar at runtime to pickup this
-change.
diff --git a/docs/dist/doc/README-1811.adoc b/docs/dist/doc/README-1811.adoc
deleted file mode 100644
index dedbc0463..000000000
--- a/docs/dist/doc/README-1811.adoc
+++ /dev/null
@@ -1,19 +0,0 @@
-== AspectJ 1.8.11
-
-_© Copyright 2017 Contributors. All rights reserved._
-
-_Release info: 1.8.11 available 26-Sep-2017_
-
-This release is a small compatibility release to improve the behaviour
-of the AspectJ 1.8 line on JDK9. Importantly it includes a change that
-knows about the Java 9 version information and so does not get confused
-and think it is running on something really old (which typically
-manifests as it complaining about annotations not being supported on
-this level of Java).
-
-With that change this release is usable for Spring AOP use cases because
-that is doing runtime pointcut matching with proxy creation rather than
-actual weaving. Although if you using Spring AOP with class level
-annotation retention there may still be issues. If you experience
-problems or need to do actual weaving on JDK9, please use AspectJ9
-instead.
diff --git a/docs/dist/doc/README-182.adoc b/docs/dist/doc/README-182.adoc
deleted file mode 100644
index a49213617..000000000
--- a/docs/dist/doc/README-182.adoc
+++ /dev/null
@@ -1,162 +0,0 @@
-== AspectJ 1.8.2
-
-_© Copyright 2014 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.8.2 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.2;[here]
-
-_Release info: 1.8.2 available 14-Aug-2014_
-
-=== Notable changes
-
-Although only a few bugs have been fixed here, they are quite important
-ones:
-
-==== Update to more recent Eclipse Compiler
-
-AspectJ is now based on a more up to date Eclipse compiler level (git
-hash 2b07958) so includes all the latest fixes
-
-==== Correct handling of RuntimeInvisibleTypeAnnotations (type annotations without runtime visibility)
-
-For anyone weaving code containing these kind of type annotations, this
-is an important fix. Although AspectJ does not currently support
-pointcuts matching on these kinds of annotation it was crashing when
-they were encountered. That is now fixed.
-
-==== Annotation processing
-
-A very long standing issue, the AspectJ compiler now supports annotation
-processors thanks to some work by Sergey Stupin.
-
-Here is a short example, a very basic annotation and application:
-
-===== Marker.java
-
-[source, java]
-....
-import java.lang.annotation.Retention;
-import java.lang.annotation.RetentionPolicy;
-
-@Retention(RetentionPolicy.RUNTIME)
-public @interface Marker { }
-....
-
-===== Code.java
-
-[source, java]
-....
-public class Code {
-
-  public static void main(String []argv) {
-    new Code().moo();
-    new Code().boo();
-    new Code().too();
-    new Code().woo();
-  }
-
-  public void moo() {}
-
-  @Marker
-  public void boo() {}
-
-  @Marker
-  public void too() {}
-
-  public void woo() {}
-}
-....
-
-And now a basic annotation processor. This processor will find methods
-in the source marked with the annotation Marker and for each one
-generate an aspect tailored to advising that method (this *is* a
-contrived demo!)
-
-===== DemoProcessor.java
-
-[source, java]
-....
-import java.io.*;
-import javax.tools.*;
-import java.util.*;
-import javax.annotation.processing.*;
-import javax.lang.model.*;
-import javax.lang.model.element.*;
-
-@SupportedAnnotationTypes(value= {"*"})
-@SupportedSourceVersion(SourceVersion.RELEASE_6)
-public class DemoProcessor extends AbstractProcessor {
-
-  private Filer filer;
-
-  @Override
-  public void init(ProcessingEnvironment env) {
-    filer = env.getFiler();
-  }
-
-  @Override
-  public boolean process(Set elements, RoundEnvironment env) {
-    // Discover anything marked with @Marker
-    for (Element element: env.getElementsAnnotatedWith(Marker.class)) {
-      if (element.getKind() == ElementKind.METHOD) {
-        // For any methods we find, create an aspect:
-        String methodName = element.getSimpleName().toString();
-        String aspectText =
-            "public aspect Advise_"+methodName+" {\n"+
-            "  before(): execution(* "+methodName+"(..)) {\n"+
-            "    System.out.println(\""+methodName+" running\");\n"+
-            "  }\n"+
-            "}\n";
-        try {
-          JavaFileObject file = filer.createSourceFile("Advise_"+methodName, element);
-          file.openWriter().append(aspectText).close();
-          System.out.println("Generated aspect to advise "+element.getSimpleName());
-        } catch (IOException ioe) {
-          // already creates message can appear if processor runs more than once
-          if (!ioe.getMessage().contains("already created")) {
-            ioe.printStackTrace();
-          }
-        }
-      }
-    }
-    return true;
-  }
-}
-....
-
-With those sources, we compile the processor:
-
-[source, text]
-....
-ajc -1.6 DemoProcessor.java Marker.java
-....
-
-Now compile the code with the processor specified:
-
-[source, text]
-....
-ajc -1.6 -processor DemoProcessor -showWeaveInfo Code.java Marker.java
-....
-
-[source, text]
-....
-Generated aspect to advise too
-Generated aspect to advise boo
-Join point 'method-execution(void Code.boo())' in Type 'Code' (Code.java:14) advised by before advice from 'Advise_boo' (Advise_boo.java:2)
-Join point 'method-execution(void Code.too())' in Type 'Code' (Code.java:17) advised by before advice from 'Advise_too' (Advise_too.java:2)
-....
-
-Notice the processor generates the aspects and then they are woven into
-the code being compiled immediately.
-
-Finally we can run it:
-
-[source, text]
-....
-java Code
-boo running
-too running
-....
-
-*Note:* There is still work to be done to get annotation processors
-behaving under AJDT.
diff --git a/docs/dist/doc/README-183.adoc b/docs/dist/doc/README-183.adoc
deleted file mode 100644
index 0d114d1f2..000000000
--- a/docs/dist/doc/README-183.adoc
+++ /dev/null
@@ -1,118 +0,0 @@
-== AspectJ 1.8.3
-
-_© Copyright 2014 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.8.3 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.3;[here]
-
-_Release info: 1.8.3 available 22-Oct-2014_
-
-=== Notable changes
-
-==== Conditional aspect activation with @RequiredTypes - https://bugs.eclipse.org/bugs/show_bug.cgi?id=436653[Issue 436653]
-
-AspectJ is sometimes used to create aspect libraries. These libraries
-contain a number of aspects often covering a variety of domains. The
-library might typically be available as a jar and contains a single
-aop.xml file that names all the aspects. The library is then consumed by
-some application. However, the application may not need to use all those
-aspects but because they are listed in the aop.xml they will be
-'active'. Now the pointcuts in those unused aspects may not match
-anything in the application and could be considered harmless but the
-pointcuts and the aspects themselves may have references to types in
-other libraries that the application does not have around. This can lead
-to unhelpful "can't find type" messages and currently requires the user
-to add unnecessary entries to their build dependencies just to keep the
-unused aspects happy.
-
-With AspectJ 1.8.3 it is now possible to express a constraint on an
-aspect. The @RequiredTypes annotation specifies one or more fully
-qualified types that must be discoverable on the classpath in order for
-the aspect to activate. Using this there is no need to add those
-extraneous dependencies to an applications build classpath.
-
-Example:
-
-[source, java]
-....
-import org.aspectj.lang.annotation.*;
-
-@RequiredTypes("com.foo.Bar")
-public aspect Foo {
-  before(): execution(@com.foo.Bar * *(..)) {}
-}
-....
-
-If the above aspect is listed in an aop.xml for loadtime weaving or
-passed on the aspectpath for compile time weaving, if the type
-'com.foo.Bar' is not accessible on the classpath then the aspect will be
-turned off and the pointcut will have no effect. There will be no
-attempt made to match it and so no unhelpful "can't find type" messages.
-
-==== cflow and the pre-initialization joinpoint changes due to Java 7 verifier modifications - https://bugs.eclipse.org/bugs/show_bug.cgi?id=443477[Issue 443477]
-
-There has been a change in the Java7 verifier in a recent patch release
-of Java7 (update 67) that causes a verify error for usage of a
-particular AspectJ construct. The problem occurs if you are using cflow
-and it hits the preinitialization join point. The pattern of code
-generated in that case causes the verifyerror. In this release of
-AspectJ we have taken the 'quick' approach to solving this, namely to
-avoid advising preinitialization with the cflow construct. This problem
-appears to come up when the aspect is non-optimal anyway and hitting
-preinitialization was never really intended by the pointcut writer. For
-example:
-
-[source, java]
-....
-execution(* foo(..)) && cflow(within(Bar))
-....
-
-The use of cflow and within there will actually hit *a lot* of
-joinpoints, many of which the user probably didn't mean to. It feels
-like we actually need a warning to indicate the pointcut is probably
-suboptimal. What the user probably meant was something more like this:
-
-[source, java]
-....
-execution(* foo(..)) && cflow(execution(* Bar.*(..))
-....
-
-or
-
-[source, java]
-....
-execution(* foo(..)) && cflow(within(Bar) && execution(* *(..)))
-....
-
-But even if they did want the less optimal form of cflow there still
-seems little use in applying it to pre-initialization - that is your cue
-to raise an AspectJ bug with a realistic use case inside that proves
-this an invalid assumption :)
-
-==== around advice and lambdas - https://bugs.eclipse.org/bugs/show_bug.cgi?id=445395[Issue 445395]
-
-For optimal performance, where possible, AspectJ tries to inline around
-advice when it applies at a joinpoint. There are few characteristics of
-a joinpoint match that can prevent this but we do try to inline where we
-can (the inlining can be manually turned off via -XnoInline).
-
-Inlining of around advice basically means copying the advice
-instructions into the target class. This causes a problem when the
-advice uses lambdas. Lambda usage is currently implemented in java
-compilers by generating invokedynamic bytecode instructions that
-reference bootstrap methods created in the class and a helper method
-generated in the class containing the lambda code. When the
-invokedynamic is encountered at runtime, some magic happens and the
-bootstrap method is used to generate a class on the fly that calls the
-particular lambda method. All this 'extra stuff' breaks the basic
-inlining algorithm that simply copies the advice bytecode into the
-target. Effectively the inlining process needs to become much more
-sophisticated and copy the bootstrap methods and the lambda helper
-methods, avoiding clashes with existing bootstrap/helpers in the target.
-
-Prior to AspectJ 1.8.3 when the inlining failed you would get a horrible
-class cast exception that mentions constant pool entries (because the
-bootstrap method hadn't been copied over to the target). Temporarily in
-1.8.3 we are turning off inlining of around advice containing lambdas,
-which will at least avoid the failure, with the longer term goal of
-improving the inlining process to do all the necessary extra work.
diff --git a/docs/dist/doc/README-184.adoc b/docs/dist/doc/README-184.adoc
deleted file mode 100644
index 1e8799cc4..000000000
--- a/docs/dist/doc/README-184.adoc
+++ /dev/null
@@ -1,29 +0,0 @@
-== AspectJ 1.8.4
-
-_© Copyright 2014 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.8.4 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.4;[here]
-
-_Release info: 1.8.4 available 6-Nov-2014_
-
-=== Notable changes
-
-==== Support for is(FinalType)
-
-AspectJ has had type category type patterns since version 1.6.9, see the
-https://www.eclipse.org/aspectj/doc/released/README-169.html[README].
-This enabled pointcuts to include is(..) clauses to specify which kinds
-of type they were or were not interested in matching, e.g. !within(* &&
-is(InnerType)) means not within innertypes. In 1.8.4 it is now possible
-to recognize (for inclusion or exclusion) final types with
-is(FinalType).
-
-==== thisAspectInstance correctly handled with -1.8
-
-This is the key fix in this release. Some products based on AspectJ were
-using the thisAspectInstance feature (see
-https://www.eclipse.org/aspectj/doc/released/README-1612.html[README
-1.6.12] for more info on the feature). Unfortunately if specifying -1.8
-compliance and using the feature an error would be reported at compile
-time of the aspect. This is now fixed.
diff --git a/docs/dist/doc/README-185.adoc b/docs/dist/doc/README-185.adoc
deleted file mode 100644
index 22fdcee3f..000000000
--- a/docs/dist/doc/README-185.adoc
+++ /dev/null
@@ -1,14 +0,0 @@
-== AspectJ 1.8.5
-
-_© Copyright 2015 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.8.5 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.5;[here]
-
-_Release info: 1.8.5 available 28-Jan-2015_
-
-=== Notable changes
-
-The most important fixes in 1.8.5 are JDT compiler fixes that it
-includes
-(https://bugs.eclipse.org/bugs/show_bug.cgi?id=455277[455277],https://bugs.eclipse.org/bugs/show_bug.cgi?id=458660[458660]).
diff --git a/docs/dist/doc/README-186.adoc b/docs/dist/doc/README-186.adoc
deleted file mode 100644
index 9a2129414..000000000
--- a/docs/dist/doc/README-186.adoc
+++ /dev/null
@@ -1,8 +0,0 @@
-== AspectJ 1.8.6
-
-_© Copyright 2015 Contributors. All rights reserved._
-
-_Release info: 1.8.6 available 5-Jun-2015_
-
-The full list of resolved issues in 1.8.6 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.6;[here]
diff --git a/docs/dist/doc/README-187.adoc b/docs/dist/doc/README-187.adoc
deleted file mode 100644
index 5d4c0de6b..000000000
--- a/docs/dist/doc/README-187.adoc
+++ /dev/null
@@ -1,127 +0,0 @@
-== AspectJ 1.8.7
-
-_© Copyright 2015 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.8.7 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.7;[here]
-
-_Release info: 1.8.7 available 9-Sep-2015_
-
-=== Notable changes
-
-==== ajdoc
-
-The ajdoc tool has been fixed! It is now working again if run on a 1.7
-JDK.
-
-==== Dynamic weaver attachment
-
-The AspectJ loadtime weaving agent can now be dynamically attached to a
-JVM after it has started (you don't need to use -javaagent). This offers
-extra flexibility but obviously any classes loaded before attachment
-will not be woven.
-
-Here is a simple aspect:
-
-[source, java]
-....
-public aspect Azpect {
-  before(): execution(* *(..)) {
-    System.out.println(thisJoinPointStaticPart);
-  }
-}
-....
-
-Compiled via:
-
-[source, text]
-....
-ajc -1.8 Azpect.java -outxml
-....
-
-This produces a compiled class Azpect.class and a file
-META-INF/aop-ajc.xml.
-
-I then have this sample application (same directory):
-
-[source, java]
-....
-import java.lang.management.ManagementFactory;
-import org.aspectj.weaver.loadtime.Agent;
-import com.sun.tools.attach.VirtualMachine;
-
-public class Application {
-
-  public static void main(String[] args) {
-    if (!isAspectJAgentLoaded())
-      System.err.println("WARNING: AspectJ weaving agent not loaded");
-    new Sample().doSomething();
-  }
-
-  public static boolean isAspectJAgentLoaded() {
-    try {
-      Agent.getInstrumentation();
-    } catch (NoClassDefFoundError e) {
-      System.out.println(e);
-      return false;
-    } catch (UnsupportedOperationException e) {
-      System.out.println(e);
-      return dynamicallyLoadAspectJAgent();
-    }
-    return true;
-  }
-
-  public static boolean dynamicallyLoadAspectJAgent() {
-    String nameOfRunningVM = ManagementFactory.getRuntimeMXBean().getName();
-    int p = nameOfRunningVM.indexOf('@');
-    String pid = nameOfRunningVM.substring(0, p);
-    try {
-      VirtualMachine vm = VirtualMachine.attach(pid);
-      String jarFilePath = System.getProperty("AGENT_PATH");
-      vm.loadAgent(jarFilePath);
-      vm.detach();
-    } catch (Exception e) {
-      System.out.println(e);
-      return false;
-    }
-    return true;
-  }
-}
-....
-
-And this Sample class:
-
-[source, java]
-....
-public class Sample {
-    public void doSomething() {
-        System.out.println("Do something");
-        System.out.println("Square of 7 = " + square(7));
-    }
-
-    private int square(int i) {
-        return i * i;
-    }
-}
-....
-
-Compile these with javac, *but you must have the aspectjweaver and the
-JDK tools.jar on your classpath*.
-
-Once compiled we can run it:
-
-[source, text]
-....
-java -DAGENT_PATH=<path-to>/aspectjweaver.jar Application
-....
-
-What does it do? The main method calls the function that detects whether
-the agent is attached, if it is not then it programmatically attaches it
-using the VirtualMachine class. Then the main method accesses the Sample
-class. At this point in program execution the Sample class is loaded and
-because the agent has been attached it gets woven. Notice that the
-Application class itself is not woven because it was loaded prior to
-agent attachment.
-
-Thanks to Alexander Kriegisch for the sample code and the patch to add
-this behaviour to AspectJ.
diff --git a/docs/dist/doc/README-188.adoc b/docs/dist/doc/README-188.adoc
deleted file mode 100644
index 12b59eeb9..000000000
--- a/docs/dist/doc/README-188.adoc
+++ /dev/null
@@ -1,17 +0,0 @@
-== AspectJ 1.8.8
-
-_© Copyright 2016 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.8.8 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.8;[here]
-
-_Release info: 1.8.8 available 7-Jan-2016_
-
-=== Notable changes
-
-==== Around advice on default methods
-
-In previous releases attempting to apply around advice to default
-methods would create methods with rogue modifiers in the interface
-declaring the default method (loading these interfaces would then result
-in a verifier error). This has now been fixed.
diff --git a/docs/dist/doc/README-189.adoc b/docs/dist/doc/README-189.adoc
deleted file mode 100644
index f24bb1223..000000000
--- a/docs/dist/doc/README-189.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-== AspectJ 1.8.9
-
-_© Copyright 2016 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.8.9 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?query_format=advanced;bug_status=RESOLVED;bug_status=VERIFIED;bug_status=CLOSED;product=AspectJ;target_milestone=1.8.9;[here]
-
-_Release info: 1.8.9 available 14-Mar-2016_
-
-=== Notable changes
-
-The JDT compiler inside AspectJ has been upgraded to the Eclipse Mars.2
-level (commit #a7bba8b1).
diff --git a/docs/dist/doc/README-190.adoc b/docs/dist/doc/README-190.adoc
deleted file mode 100644
index 06872691c..000000000
--- a/docs/dist/doc/README-190.adoc
+++ /dev/null
@@ -1,341 +0,0 @@
-== AspectJ 1.9.0
-
-_© Copyright 2018 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.9.0 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.0[here]
-
-_Release info: 1.9.0 available 2-Apr-2018_
-
-=== Improved runtime interface
-
-New factory methods have been added to the AspectJ runtime. This is an
-attempt to more optimally create `thisJoinPoint` and
-`thisEnclosingJoinPoint` objects. The generated code that invokes these
-now also uses the ability for the `LDC` bytecode instruction to load class
-constants directly (this replaces what was happening previously where
-generated code referenced string class names and class-loading was being
-done from the AspectJ runtime as the woven application was starting).
-
-This is turned on by using `-Xajruntimetarget:1.9`. This option was used
-previously to enable users to target an old runtime if they knew that
-old runtime is all that was available at some deployed target. The new
-generation mechanism is not the default, not until it has had a bit more
-testing out in the wild.
-
-The changes to generated code have a couple of potential side effects:
-
-* *overall size*: the woven code may be smaller due to the use of
-smaller string constant pieces in the generated code (previously strings
-were smashed together in the generated code and then taken apart by
-AspectJ at runtime). Since the pieces are smaller, they can be shared
-across other uses in the class file.
-* *method size*: although the overall class may be smaller there are
-more instructions involved in preparing the data for invocation of the
-new joinpoint factory methods. It is possible if you have a lot of
-joinpoints that we might blow the 64k instruction limit for the
-`ajc$preClinit` method (where the factory invocation code is generated).
-Please provide feedback if this happens to you!
-
-In anticipation of not all build plugins supporting that
-`-Xajruntimetarget` option, you can now specify these kinds of option in
-the `ASPECTJ_OPTS` environment variable. Set that in your environment:
-
-[source, text]
-....
-export ASPECTJ_OPTS="-Xajruntimetarget:1.9"
-....
-
-And it should get picked up by AspectJ when it runs.
-
-== AspectJ 1.9.0.RC4
-
-_Release info: 1.9.0.RC4 available 21-Feb-2018_
-
-Primary changes in RC4 are to add support for `<compilerArg>` in the Ant
-task. This enables users of the Ant task to pass in options supported by
-the underlying AspectJ but not yet surfaced elsewhere. Particularly
-useful with Java9 which includes a number of module related commands.
-For example, here is an `iajc` usage with `compilerArg` that is passing
-`--add-modules java.xml.bind`:
-
-[source, xml]
-....
-<iajc destdir="bin" failonerror="true"
-  showWeaveInfo="true" source="1.9" target="1.9"
-  debug="true"  fork="true" maxmem="256m">
-
-  <compilerArg value="--add-modules"/>
-  <compilerArg value="java.xml.bind"/>
-  <src path="src" />
-  <classpath>
-    <pathelement location="${aspectj.home}/lib/aspectjrt.jar"/>
-  </classpath>
-
-</iajc>
-....
-
-== AspectJ 1.9.0.RC3
-
-_Release info: 1.9.0.RC3 available 5-Feb-2018_
-
-Primary changes in RC3 are to upgrade JDT and pickup all the fixes for
-Java9 that have gone into it over the last few months.
-
-== AspectJ 1.9.0.RC2
-
-_Release info: 1.9.0.RC2 available 9-Nov-2017_
-
-Key change in 1.9.0.RC2 is actually to be more tolerant of JDK10. The
-version handling has been somewhat overhauled so AspectJ 9 will behave
-better on Java 10 and future JDKs. This should put AspectJ in a better
-place if new JDK versions are going to arrive thick and fast.
-
-== AspectJ 1.9.0.RC1
-
-_Release info: 1.9.0.RC1 available 20-Oct-2017_
-
-This is the first release candidate of AspectJ 1.9.0 - the version of
-AspectJ to be based on Java9. It includes a recent version of the
-Eclipse Java9 compiler (from jdt core, commit #062ac5d7a6bf9).
-
-=== Automatic Modules
-
-AspectJ can now be used with the new module system available in Java9.
-The key jars in AspectJ have been given automatic module names. The
-automatic module name is `org.aspectj.runtime` for the `aspectjrt` module:
-
-[source, text]
-....
-$ java --module-path <pathto>/lib/aspectjrt.jar --list-modules | grep aspectj
-
-org.aspectj.runtime file:///<pathto>/lib/aspectjrt.jar automatic
-....
-
-And similarly `org.aspectj.weaver` and `org.aspectj.tools` for `aspectjweaver`
-and `aspectjtools`, respectively:
-
-[source, text]
-....
-$ java --module-path <pathto>/lib/aspectjweaver.jar --describe-module org.aspectj.weaver
-
-org.aspectj.weaver file:///<pathto>/lib/aspectjweaver.jar automatic
-requires java.base mandated
-contains aj.org.objectweb.asm
-contains aj.org.objectweb.asm.signature
-contains org.aspectj.apache.bcel
-contains org.aspectj.apache.bcel.classfile
-contains org.aspectj.apache.bcel.classfile.annotation
-contains org.aspectj.apache.bcel.generic
-contains org.aspectj.apache.bcel.util
-contains org.aspectj.asm
-contains org.aspectj.asm.internal
-...
-....
-
-=== Building woven modules
-
-AspectJ understands `module-info.java` source files and building modules
-that include aspects. Here is an example:
-
-[source, java]
-....
-// module-info.java
-
-module demo {
-  exports pkg;
-  requires org.aspectj.runtime;
-}
-
-// pkg/Demo.java
-
-package pkg;
-
-public class Demo {
-  public static void main(String[] argv) {
-    System.out.println("Demo running");
-  }
-}
-
-// otherpkg/Azpect.java
-
-package otherpkg;
-
-public aspect Azpect {
-  before(): execution(* *(..)) && !within(Azpect) {
-    System.out.println("Azpect running");
-  }
-}
-....
-
-We can now build those into a module:
-
-[source, text]
-....
-$ ajc -1.9 module-info.java otherpkg/Azpect.java pkg/Demo.java -outjar demo.jar
-
-...
-module-info.java:3 [error] org.aspectj.runtime cannot be resolved to a module
-...
-....
-
-Wait, that failed! Yes, `aspectjrt.jar` (which includes the required
-`org.aspectj.weaver` module) wasn't supplied. We need to pass it on the
-module-path:
-
-[source, text]
-....
-$ ajc -1.9 --module-path <pathto>/aspectjrt.jar module-info.java otherpkg/Azpect.java pkg/Demo.java -outjar demo.jar
-....
-
-Now we have a demo module we can run:
-
-[source, text]
-....
-$ java --module-path <pathto>/aspectjrt.jar:demo.jar --module demo/pkg.Demo
-
-Azpect running
-Demo running
-....
-
-That's it!
-
-=== Binary weaving with modules
-
-A module is really just a jar with a _module-info_ descriptor. As such, you
-can simply pass a module on the _inpath_ and binary-weave it with other
-aspects. Take the module we built above, let's weave into it again:
-
-[source, java]
-....
-// extra/AnotherAzpect.java
-
-package extra;
-
-public aspect AnotherAzpect {
-  before(): execution(* *(..)) && !within(*Azpect) {
-    System.out.println("AnotherAzpect running");
-  }
-}
-....
-
-[source, text]
-....
-$ ajc -inpath demo.jar AnotherAzpect.java -outjar newdemo.jar
-....
-
-Notice how there was no complaint here that the `org.aspectj.runtime`
-module hadn't been passed in. That is because inpath was being used
-which doesn't treat specified jars as modules (and so does not check
-dependencies). There is no _module-inpath_ right now.
-
-Because the new JAR produced includes the compiled aspect, the
-_module-info_ specification inside is still correct, so we can run it
-exactly as before:
-
-[source, text]
-....
-$ java --module-path ~/installs/aspectj190rc1/lib/aspectjrt.jar:newdemo.jar --module demo/pkg.Demo
-
-Azpect running
-AnotherAzpect running
-Demo running
-....
-
-=== Faster Spring AOP
-
-Dave Syer recently created a https://github.com/dsyer/spring-boot-aspectj[series of benchmarks] for checking the speed
-of Spring-AspectJ.
-
-Here we can see the numbers for AspectJ 1.8.11 (on an older Macbook
-Pro):
-
-[source, text]
-....
-Benchmark                 (scale)  Mode  Cnt   Score   Error  Units
-StartupBenchmark.ltw          N/A  avgt   10   2.553 ~ 0.030   s/op
-StartupBenchmark.ltw_100      N/A  avgt   10   2.608 ~ 0.046   s/op
-StartupBenchmark.spring     v0_10  avgt   10   2.120 ~ 0.148   s/op
-StartupBenchmark.spring     v1_10  avgt   10   2.219 ~ 0.066   s/op
-StartupBenchmark.spring    v1_100  avgt   10   2.244 ~ 0.030   s/op
-StartupBenchmark.spring    v10_50  avgt   10   2.950 ~ 0.026   s/op
-StartupBenchmark.spring    v20_50  avgt   10   3.854 ~ 0.090   s/op
-StartupBenchmark.spring   v20_100  avgt   10   4.003 ~ 0.038   s/op
-StartupBenchmark.spring     a0_10  avgt   10   2.067 ~ 0.019   s/op
-StartupBenchmark.spring     a1_10  avgt   10   2.724 ~ 0.023   s/op
-StartupBenchmark.spring    a1_100  avgt   10   2.778 ~ 0.057   s/op
-StartupBenchmark.spring    a10_50  avgt   10   7.191 ~ 0.134   s/op
-StartupBenchmark.spring   a10_100  avgt   10   7.191 ~ 0.168   s/op
-StartupBenchmark.spring    a20_50  avgt   10  11.541 ~ 0.158   s/op
-StartupBenchmark.spring   a20_100  avgt   10  11.464 ~ 0.157   s/op
-....
-
-So this is the average startup of an app affected by aspects applying to
-the beans involved. Where numbers are referenced the first is the number
-of aspects/pointcuts and the second is the number of beans. The 'a'
-indicates an annotation based pointcut vs a non-annotation based
-pointcut ('v'). Notice things are much worse for annotation based
-pointcuts. At 20 pointcuts and 50 beans the app is 9 seconds slower to
-startup. +
-
-In AspectJ 1.8.12 and 1.9.0.RC1 some work has been done here. The key
-change is to recognize that the use of annotations with runtime
-retention is much more likely than annotations with class level
-retention. Retrieving annotations with class retention is costly because
-we must open the bytes for the class file and dig around in there (vs
-runtime retention which are immediately accessible by reflection on the
-types). In 1.8.11 the actual type of the annotation involved in the
-matching is ignored and the code will fetch *all* the annotations on the
-type/method/field being matched against. So even if the match is looking
-for a runtime retention annotation, we were doing the costly thing of
-fetching any class retention annotations. In 1.8.12/1.9.0.RC1 we take
-the type of the match annotation into account - allowing us to skip
-opening the classfiles in many cases. There is also some deeper work on
-activating caches that were not previously being used correctly but the
-primary change is factoring in the annotation type.
-
-What difference does that make? AspectJ 1.9.0.RC1:
-
-[source, text]
-....
-Benchmark                 (scale)  Mode  Cnt  Score   Error  Units
-StartupBenchmark.ltw          N/A  avgt   10  2.568 ~ 0.035   s/op
-StartupBenchmark.ltw_100      N/A  avgt   10  2.622 ~ 0.075   s/op
-StartupBenchmark.spring     v0_10  avgt   10  2.096 ~ 0.054   s/op
-StartupBenchmark.spring     v1_10  avgt   10  2.206 ~ 0.031   s/op
-StartupBenchmark.spring    v1_100  avgt   10  2.252 ~ 0.025   s/op
-StartupBenchmark.spring    v10_50  avgt   10  2.979 ~ 0.071   s/op
-StartupBenchmark.spring    v20_50  avgt   10  3.851 ~ 0.058   s/op
-StartupBenchmark.spring   v20_100  avgt   10  4.000 ~ 0.046   s/op
-StartupBenchmark.spring     a0_10  avgt   10  2.071 ~ 0.026   s/op
-StartupBenchmark.spring     a1_10  avgt   10  2.182 ~ 0.032   s/op
-StartupBenchmark.spring    a1_100  avgt   10  2.272 ~ 0.024   s/op
-StartupBenchmark.spring    a10_50  avgt   10  2.557 ~ 0.027   s/op
-StartupBenchmark.spring   a10_100  avgt   10  2.598 ~ 0.040   s/op
-StartupBenchmark.spring    a20_50  avgt   10  2.961 ~ 0.043   s/op
-StartupBenchmark.spring   a20_100  avgt   10  3.093 ~ 0.098   s/op
-....
-
-Look at the a20_100 case - instead of impacting start time by 9 seconds,
-it impacts it by 1 second.
-
-=== More to come...
-
-* Eclipse JDT Java 9 support is still being actively worked on and lots
-of fixes will be coming through over the next few months and included in
-AspectJ 1.9.X revisions.
-
-* AspectJ does not currently modify `module-info.java` files. An aspect
-from one module applying to code in another module clearly introduces a
-dependency between those two modules. There is no reason - other than
-time! - that this can't be done.
-(https://bugs.eclipse.org/bugs/show_bug.cgi?id=526244[Issue 526244])
-
-* Related to that AspectJ, on detection of aspects should be able to
-automatically introduce the `requires org.aspectj.runtime` to the
-_module-info_. (https://bugs.eclipse.org/bugs/show_bug.cgi?id=526242[Issue
-526242])
-
-* Module-aware variants of AspectJ paths: `--module-inpath`,
-`--module-aspectpath`.
-(https://bugs.eclipse.org/bugs/show_bug.cgi?id=526243[Issue 526243])
diff --git a/docs/dist/doc/README-191.adoc b/docs/dist/doc/README-191.adoc
deleted file mode 100644
index e5aeac249..000000000
--- a/docs/dist/doc/README-191.adoc
+++ /dev/null
@@ -1,31 +0,0 @@
-== AspectJ 1.9.1
-
-_© Copyright 2018 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.9.1 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.1[here]
-
-_Release info: 1.9.1 available 20-Apr-2018_
-
-=== Java 10 support
-
-AspectJ has updated to a recent JDT compiler version (commit
-#abe06abe4ce1 - 9-Apr-2018). With this update it now supports Java10.
-This means you can use the `var` support. A simple example of combining
-var with an aspect:
-
-[source, java]
-....
-public class Code3 {
-  public static void main(String []argv) {
-    var x = "hello";
-    System.out.println(x.getClass());
-  }
-}
-
-aspect X {
-  before(): call(* *.getClass()) && target(String) {
-    System.out.println(thisJoinPointStaticPart);
-  }
-}
-....
diff --git a/docs/dist/doc/README-1919.adoc b/docs/dist/doc/README-1919.adoc
deleted file mode 100644
index 07618a02c..000000000
--- a/docs/dist/doc/README-1919.adoc
+++ /dev/null
@@ -1,92 +0,0 @@
-== AspectJ 1.9.19
-
-_© Copyright 2022 Contributors. All rights reserved._
-
-== AspectJ 1.9.19
-
-_© Copyright 2022 Contributors. All rights reserved._
-
-_Release info: 1.9.19 available 21-Dec-2022_
-
-Please note that Bugzilla for issue management is deprecated and new issues should be filed as
-https://github.com/eclipse/org.aspectj/issues/new[GitHub issues]. The list of issues addressed for 1.9.19 can be found
-here:
-
-* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.19[GitHub 1.9.19]
-* https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.19[Bugzilla 1.9.19]
-
-=== New features
-
-AspectJ 1.9.19 supports https://openjdk.java.net/projects/jdk/19/[Java 19] and its final, preview and incubator
-features, such as:
-
-* Record patterns (preview)
-* Virtual threads (preview)
-* Pattern matching for `switch` (preview 3)
-* Structured concurrency (incubator)
-
-Please note that the upstream Eclipse Java Compiler (ECJ) which the AspectJ Compiler (AJC) is a fork of still has some
-open issues concerning Java 19 preview feature support, see the list in
-https://github.com/eclipse/org.aspectj/issues/184#issuecomment-1272254940[this comment]. AJC therefore inherits the same
-problems for the specific cases described in the linked issues.
-
-=== Improvements
-
-* Improve condy (constant dynamic) support. Together with some custom compilation or weaving options, this helps to
-  avoid a problem when using JaCoCo together with AspectJ, see
-  https://github.com/eclipse/org.aspectj/issues/170#issuecomment-1214163297[this comment in #170] for more details.
-
-=== Code examples
-
-You can find some sample code in the AspectJ test suite under the respective AspectJ version in which the features were
-first supported (possibly as JVM preview features):
-
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features198/java17[Pattern matching for switch (preview 1)]
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features199/java18[Pattern matching for switch (preview 2)]
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features1919/java19[Pattern matching for switch (preview 3),
-  record patterns (preview 1)]
-* Please note that presently there is no specific sample code for virtual threads and structured concurrency in the
-  AspectJ code base, because these are just new APIs, no Java language features. You can find sample code for these
-  concurrency features elsewhere, e.g. in the corresponding JEPs. In AspectJ, they should just work transparently like
-  any other Java API.
-
-=== Other changes and bug fixes
-
-* Fix (or rather work around) an old bug occurring when compiling or weaving code using ITD to declare annotations with
-  `SOURCE` retention on types, methods, constructors or fields. While declaring such annotations does not make sense to
-  begin with, at least the AspectJ weaver or compiler should handle the situation gracefully, which now it does by
-  simply ignoring errors caused by it. See https://bugs.eclipse.org/bugs/show_bug.cgi?id=366085[Bugzilla #366085] and
-  https://github.com/eclipse/org.aspectj/pull/196[pull request #196]. Better than this workaround would be for the
-  compiler or weaver to actually print a warning when meeting source level annotations in declare statements. Hence,
-  follow-up issue https://github.com/eclipse/org.aspectj/issues/201[#201] was created.
-* Remove legacy AspectJ Browser code and documentation.
-* Thanks to Andrey Turbanov for several clean code contributions.
-
-=== AspectJ usage hints
-
-==== AspectJ compiler build system requirements
-
-Since 1.9.8, the AspectJ compiler `ajc` (contained in the `aspectjtools` library) no longer works on JDKs 8 to 10. The
-minimum compile-time requirement is now JDK 11 due to upstream changes in the Eclipse Java Compiler (subset of JDT
-Core), which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling
-plain Java code or using plain Java ITD constructs which do not require the AspectJ runtime `aspectjrt`, but the
-compiler itself needs JDK 11+. Just like in previous AspectJ versions, both the runtime `aspectjrt` and the load-time
-weaver `aspectjweaver` still only require JRE 8+.
-
-==== Use LTW on Java 16+
-
-Please note that if you want to use load-time weaving on Java 16+, the weaving agent collides with
-https://openjdk.java.net/jeps/396[JEP 396 (Strongly Encapsulate JDK Internals by Default)]. Therefore, you need to set
-the JVM parameter `--add-opens java.base/java.lang=ALL-UNNAMED` in order to enable aspect weaving. This is due to the
-fact that the weaver uses internal APIs for which we have not found an adequate replacement yet when defining classes
-in different classloaders.
-
-==== Compile with Java preview features
-
-For features marked as preview on a given JDK, you need to compile with `ajc --enable-preview` and run with
-`java --enable-preview` on that JDK.
-
-Please note, that you cannot run code compiled with preview features on any other JDK than the one used for compilation.
-For example, records compiled with preview on JDK 15 cannot be used on JDK 16 without recompilation. This is a JVM
-limitation unrelated to AspectJ. Also, e.g. sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16. You still
-need to recompile, no matter what.
diff --git a/docs/dist/doc/README-192.adoc b/docs/dist/doc/README-192.adoc
deleted file mode 100644
index 94da278bf..000000000
--- a/docs/dist/doc/README-192.adoc
+++ /dev/null
@@ -1,13 +0,0 @@
-== AspectJ 1.9.2
-
-_© Copyright 2018 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.9.2 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.2[here]
-
-=== Java 11 support
-
-AspectJ now supports Java11. It has been updated to a more recent JDT
-compiler that supports Java 11 (JDTCore #6373b82afa49b).
-
-Available: 1.9.2 available Oct-2018
diff --git a/docs/dist/doc/README-1920.adoc b/docs/dist/doc/README-1920.adoc
deleted file mode 100644
index 51b9033e9..000000000
--- a/docs/dist/doc/README-1920.adoc
+++ /dev/null
@@ -1,109 +0,0 @@
-== AspectJ 1.9.20.1
-
-_© Copyright 2023 Contributors. All rights reserved._
-
-_Release info: 1.9.20.1 available 04-Sep-2023_
-
-This is a bugfix release for 1.9.20, fixing two problems:
-
-* https://github.com/eclipse-aspectj/aspectj/issues/257[Regression bug 257] introduced in 1.9.20 would match negated
-  type patterns like `!void` or `!String[]` incorrectly.
-* https://github.com/spring-projects/spring-framework/issues/27761[Spring issue 27761] describes a problem where
-  AspectJ, when used by Spring AOP, in rare cases falsely considered bridge methods for overridden generic methods for
-  matching, leading to falsely negative matching results. See also
-  https://github.com/eclipse-aspectj/aspectj/issues/256[AspectJ tracker issue 256]).
-
-The list of issues addressed for 1.9.20.1 can be found
-https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.20.1[here].
-
-== AspectJ 1.9.20
-
-_© Copyright 2023 Contributors. All rights reserved._
-
-_Release info: 1.9.20 available 16-Aug-2023_
-
-Please note that Bugzilla for issue management is deprecated and new issues should be filed as
-https://github.com/eclipse/org.aspectj/issues/new[GitHub issues]. The list of issues addressed for 1.9.20 can be found
-here:
-
-* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.20[GitHub 1.9.20]
-* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.20.1[GitHub 1.9.20.1]
-* https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.20[Bugzilla 1.9.20]
-
-=== New features
-
-AspectJ 1.9.20 supports https://openjdk.java.net/projects/jdk/20/[Java 20] and its final, preview and incubator
-features, such as:
-
-* Record patterns (preview)
-* Virtual threads (preview)
-* Pattern matching for `switch` (preview 3)
-* Structured concurrency (incubator)
-
-Please note, that the upstream Eclipse Java Compiler (ECJ), which the AspectJ Compiler (AJC) is a fork of, still has
-some open issues concerning Java 20 preview feature support, see the list in
-https://github.com/eclipse/org.aspectj/issues/184#issuecomment-1272254940[this comment]. AJC therefore inherits the same
-problems for the specific cases described in the linked issues.
-
-=== Improvements
-
-* Since Java 9 and the introduction of the Java Module System, the upstream Eclipse Java Compiler (ECJ) and Eclipse Java
-  Development Tools (JDT) had gone through some internal changes, enabling both the compiler and the IDE to handle new
-  Java language features. In AspectJ, some of those internal changes have not been properly upgraded for quite a while,
-  but this is now fixed. However, it might *require you to recompile your aspects and projects/classes using them.*
-  Otherwise, you might get problems in Eclipse IDE or under certain circumstances even when running newly compiled
-  aspects in older AspectJ versions and vice versa. You are on the safe side if you simply rebuild your projects. We are
-  sorry for the inconvenience, but we have to follow upstream ECJ and JDT changes.
-* Along with fixing https://github.com/eclipse-aspectj/aspectj/issues/24[GitHub bug 24], the syntax for array type
-  matching has been improved considerably. You can find some examples
-  https://github.com/eclipse-aspectj/aspectj/tree/master/tests/bugs1920/github_24[here].
-
-=== Code examples
-
-You can find some sample code in the AspectJ test suite under the respective AspectJ version in which the features were
-first supported (possibly as JVM preview features):
-
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features198/java17[Pattern matching for switch (preview 1)]
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features199/java18[Pattern matching for switch (preview 2)]
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features1919/java19[Pattern matching for switch (preview 3),
-  record patterns (preview 1)]
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features1920/java20[Pattern matching for switch (preview 4),
-  record patterns (preview 2)]
-* Please note that presently there is no specific sample code for virtual threads and structured concurrency in the
-  AspectJ code base, because these are just new APIs, no Java language features. You can find sample code for these
-  concurrency features elsewhere, e.g. in the corresponding JEPs. In AspectJ, they should just work transparently like
-  any other Java API.
-
-=== Other changes and bug fixes
-
-* About a dozen bugs have been fixed, some of them quite old. See "list of issues addressed" further above and follow
-  the link to GitHub to find out if your issue is among them.
-
-=== AspectJ usage hints
-
-==== AspectJ compiler build system requirements
-
-Since 1.9.8, the AspectJ compiler `ajc` (contained in the `aspectjtools` library) no longer works on JDKs 8 to 10. The
-minimum compile-time requirement is now JDK 11 due to upstream changes in the Eclipse Java Compiler (subset of JDT
-Core), which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling
-plain Java code or using plain Java ITD constructs which do not require the AspectJ runtime `aspectjrt`, but the
-compiler itself needs JDK 11+. Just like in previous AspectJ versions, both the runtime `aspectjrt` and the load-time
-weaver `aspectjweaver` still only require JRE 8+.
-
-==== Use LTW on Java 16+
-
-Please note that if you want to use load-time weaving on Java 16+, the weaving agent collides with
-https://openjdk.java.net/jeps/396[JEP 396 (Strongly Encapsulate JDK Internals by Default)]. Therefore, you need to set
-the JVM parameter `--add-opens java.base/java.lang=ALL-UNNAMED` in order to enable aspect weaving. This is due to the
-fact that the weaver uses internal APIs for which we have not found an adequate replacement yet when defining classes
-in different classloaders.
-
-==== Compile with Java preview features
-
-For features marked as preview on a given JDK, you need to compile with `ajc --enable-preview` and run with
-`java --enable-preview` on that JDK.
-
-Please note, that you cannot run code compiled with preview features on any other JDK than the one used for compilation.
-For example, records compiled with preview on JDK 15 cannot be used on JDK 16 without recompilation. This is a JVM
-limitation unrelated to AspectJ. Also, e.g. sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16. You still
-need to recompile, no matter what.
diff --git a/docs/dist/doc/README-1921.adoc b/docs/dist/doc/README-1921.adoc
deleted file mode 100644
index d205ed36d..000000000
--- a/docs/dist/doc/README-1921.adoc
+++ /dev/null
@@ -1,81 +0,0 @@
-== AspectJ 1.9.21
-
-_© Copyright 2023 Contributors. All rights reserved._
-
-_Release info: 1.9.21 available 11-Dec-2023_
-
-Please note that Bugzilla for issue management is deprecated and new issues should be filed as
-https://github.com/eclipse/org.aspectj/issues/new[GitHub issues]. The list of issues addressed for 1.9.21 can be found
-here:
-
-* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.21[GitHub 1.9.21]
-* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.21.1[GitHub 1.9.21.1]
-* https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.21[Bugzilla 1.9.21]
-
-=== New features
-
-AspectJ 1.9.21 supports https://openjdk.java.net/projects/jdk/21/[Java 21], its final features and a subset of preview
-features, such as:
-
-* Record patterns
-* Pattern matching for switch
-* Virtual threads
-* Sequenced collections
-* Structured concurrency (preview)
-* String templates (preview)
-* Instance main methods (preview)
-
-Unfortunately, even after holding back the AspectJ release for 3 months after JDK 21 general availability, waiting for
-Eclipse JDT Core and the Eclipse Java Compiler (ECJ) to catch up with Java 21 language features, even with Java 21
-officially supported in Eclipse 2023-12, some preview features are still unimplemented in ECJ:
-
-* Unnamed classes (preview)
-* Unnamed patterns and variables (preview)
-
-As soon as these preview features are part of the upstream ECJ we depend on, we hope to publish another AspectJ release
-to support them in the AspectJ Compiler (AJC), too.
-
-=== Improvements
-
-* In https://github.com/eclipse-aspectj/aspectj/issues/266[GitHub issue 266], exception cause reporting has been
-  improved in `ExtensibleURLClassLoader`. Thanks to Andy Russell (@euclio) for his contribution.
-
-=== Other changes and bug fixes
-
-* No major bug fixes
-
-=== AspectJ usage hints
-
-==== AspectJ compiler build system requirements
-
-Since 1.9.21, the AspectJ compiler `ajc` (contained in the `aspectjtools` library) no longer works on JDKs 11 to 16. The
-minimum compile-time requirement is now JDK 17 due to upstream changes in the Eclipse Java Compiler (subset of JDT
-Core), which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling
-plain Java code or using plain Java ITD constructs which do not require the AspectJ runtime `aspectjrt`, but the
-compiler itself needs JDK 17+. Just like in previous AspectJ versions, both the runtime `aspectjrt` and the load-time
-weaver `aspectjweaver` still only require JRE 8+.
-
-Please note: If you run `ajc` on JDKs 11-16, you will probably see an error like `java.lang.NoSuchFieldError:
-RELEASE_17`, and an _ajcore.*.txt_ dump file will be created, while running it on even older JDKs will rather yield an
-`UnsupportedClassVersionError`. See https://github.com/eclipse-aspectj/aspectj/issues/269[GitHub issue 269] for more
-details.
-
-History: Since 1.9.8, the AspectJ compiler ajc needed JDK 11+, before then JDK 8+.
-
-==== Use LTW on Java 16+
-
-Please note that if you want to use load-time weaving on Java 16+, the weaving agent collides with
-https://openjdk.java.net/jeps/396[JEP 396 (Strongly Encapsulate JDK Internals by Default)] and related subsequent
-JEPs. Therefore, you need to set the JVM parameter `--add-opens java.base/java.lang=ALL-UNNAMED` in order to enable
-aspect weaving. This is due to the fact that the weaver uses internal APIs for which we have not found an adequate
-replacement yet when defining classes in different classloaders.
-
-==== Compile with Java preview features
-
-For features marked as preview on a given JDK, you need to compile with `ajc --enable-preview` and run with
-`java --enable-preview` on that JDK.
-
-Please note, that you cannot run code compiled with preview features on any other JDK than the one used for compilation.
-For example, records compiled with preview on JDK 15 cannot be used on JDK 16 without recompilation. This is a JVM
-limitation unrelated to AspectJ. Also, e.g. sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16. You still
-need to recompile, no matter what.
diff --git a/docs/dist/doc/README-193.adoc b/docs/dist/doc/README-193.adoc
deleted file mode 100644
index aa130dbc5..000000000
--- a/docs/dist/doc/README-193.adoc
+++ /dev/null
@@ -1,75 +0,0 @@
-== AspectJ 1.9.3
-
-_© Copyright 2018 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.9.3 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.3[here]
-
-_Release info: 1.9.3 available 4-Apr-2019_
-
-AspectJ 1.9.3 supports Java12. Java12 introduces the new switch
-expression syntax, but you must activate support for that via an
-`--enable-preview` flag when using the compiler and attempting to run the
-resultant classes: Here is `Switch3.java`:
-
-[source, java]
-....
-public class Switch3 {
-  public static void main(String[] argv) {
-    System.out.println(one(Color.R));
-    System.out.println(one(Color.G));
-    System.out.println(one(Color.B));
-    System.out.println(one(Color.Y));
-  }
-
-  public static int one(Color color) {
-    int result = switch(color) {
-      case R -> foo(0);
-      case G -> foo(1);
-      case B -> foo(2);
-      default -> foo(3);
-    };
-    return result;
-  }
-
-  public static final int foo(int i) {
-    return i+1;
-  }
-}
-
-enum Color {
-  R, G, B, Y;
-}
-
-aspect X {
-  int around(): call(* foo(..)) {
-    return proceed()*3;
-  }
-}
-....
-
-Compile it with:
-
-[source, text]
-....
-$ ajc --enable-preview -showWeaveInfo -12 Switch3.java
-
-Join point 'method-call(int Switch3.foo(int))' in Type 'Switch3' (Switch3.java:12) advised by around advice from 'X' (Switch3.java:30)
-
-Join point 'method-call(int Switch3.foo(int))' in Type 'Switch3' (Switch3.java:13) advised by around advice from 'X' (Switch3.java:30)
-
-Join point 'method-call(int Switch3.foo(int))' in Type 'Switch3' (Switch3.java:14) advised by around advice from 'X' (Switch3.java:30)
-
-Join point 'method-call(int Switch3.foo(int))' in Type 'Switch3' (Switch3.java:15) advised by around advice from 'X' (Switch3.java:30)
-....
-
-Now run it:
-
-[source, text]
-....
-$ java --enable-preview Switch3
-3
-6
-9
-12
-....
diff --git a/docs/dist/doc/README-194.adoc b/docs/dist/doc/README-194.adoc
deleted file mode 100644
index 72d6ca404..000000000
--- a/docs/dist/doc/README-194.adoc
+++ /dev/null
@@ -1,25 +0,0 @@
-== AspectJ 1.9.4
-
-_© Copyright 2019 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.9.4 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.4[here]
-
-_Release info: 1.9.4 available 10-May-2019_
-
-AspectJ 1.9.4 has a couple of important fixes in it:
-
-* Due to the new maven build process being used to build release
-artifacts for the first time, there were errors in the _aspectjweaver_ JAR
-that affected the ability to use it on the command line as an agent,
-this is now fixed.
-
-* A number of users were noticing a `ClassCastException` problem, which I
-believe was due to trying to run AspectJ on one level of the JDK whilst
-targeting another. This can happen quite easily in Eclipse if running
-your Eclipse on Java 8 but developing projects targeting Java 11. The
-class cast is because Java8 couldn't understand the packaging of system
-classes post Java9 and so couldn't find `java.lang.Object`. This has now
-all been tidied up and should work much better. More details in
-https://bugs.eclipse.org/bugs/show_bug.cgi?id=546807[546807], thanks to
-Denys Khanzhyiev for some tips on getting to the right solution.
diff --git a/docs/dist/doc/README-195.adoc b/docs/dist/doc/README-195.adoc
deleted file mode 100644
index 662c561bc..000000000
--- a/docs/dist/doc/README-195.adoc
+++ /dev/null
@@ -1,54 +0,0 @@
-== AspectJ 1.9.5
-
-_© Copyright 2019 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.9.5 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.5[here]
-
-_Release info: 1.9.5 available 28-Nov-2019_
-
-AspectJ 1.9.5 supports Java13. Java13 introduces text blocks, but you
-must activate support for that via an `--enable-preview` flag when using
-the compiler and attempting to run the resultant classes: Here is
-`Code.java`:
-
-[source, java]
-....
-public class Code {
-  public static void main(String[] argv) {}
-
-  static aspect X {
-    before(): execution(* Code.main(..)) {
-    System.out.println(
-"""
-This
-is
-on
-multiple
-lines
-"""
-);
-    }
-  }
-
-}
-....
-
-Compile it with:
-
-[source, text]
-....
-$ ajc --enable-preview -13 Code.java
-....
-
-Now run it:
-
-[source, text]
-....
-$ java --enable-preview Code
-This
-is
-on
-multiple
-lines
-....
diff --git a/docs/dist/doc/README-196.adoc b/docs/dist/doc/README-196.adoc
deleted file mode 100644
index 0ecbc8967..000000000
--- a/docs/dist/doc/README-196.adoc
+++ /dev/null
@@ -1,49 +0,0 @@
-== AspectJ 1.9.6
-
-_© Copyright 2020 Contributors. All rights reserved._
-
-The full list of resolved issues in 1.9.6 is available
-https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.6[here]
-
-_Release info: 1.9.6 available 22-Jul-2020_
-
-AspectJ 1.9.6 supports Java14. Java14 introduces records, but you must
-activate support for that via an `--enable-preview` flag when using the
-compiler and attempting to run the resultant classes: Here is `Code.java`:
-
-[source, java]
-....
-public record Person(String firstName, String lastName, int age) {}
-
-public class UsingPersonRecord {
-  public static void main(String[] argv) {
-    Person p = new Person("A","B",99);
-    System.out.println(p);
-    System.out.println(p.firstName());
-  }
-}
-
-public aspect TraceRecordComponents {
-  before(): execution(public * *()) {
-    System.out.println(thisJoinPointStaticPart);
-  }
-}
-....
-
-Compile it with:
-
-[source, text]
-....
-$ ajc --enable-preview -14 Person.java UsingPersonRecord.java TraceRecordComponents.java
-....
-
-Now run it:
-
-[source, text]
-....
-$ java --enable-preview UsingPersonRecord
-execution(String Person.toString())
-Person[firstName=A, lastName=B, age=99]
-execution(String Person.firstName())
-A
-....
diff --git a/docs/dist/doc/README-197.adoc b/docs/dist/doc/README-197.adoc
deleted file mode 100644
index 1f96cd5bb..000000000
--- a/docs/dist/doc/README-197.adoc
+++ /dev/null
@@ -1,109 +0,0 @@
-== AspectJ 1.9.7
-
-_© Copyright 2021 Contributors. All rights reserved._
-
-_Release info: 1.9.7 available 24-Jun-2021_
-
-AspectJ (binaries, source code, documentation) is now distributed under
-the https://www.eclipse.org/org/documents/epl-2.0/EPL-2.0.txt[Eclipse
-Public License v 2.0].
-
-Please note, that going forward Bugzilla for issue management is
-deprecated, and new issues should be filed as
-https://github.com/eclipse/org.aspectj/issues/new[GitHub issues]. The
-list of issues addressed for 1.9.7 can be found
-https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.7[here
-for Bugzilla] and
-https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.7[here
-for GitHub issues].
-
-=== New features
-
-AspectJ 1.9.7 supports https://openjdk.java.net/projects/jdk/15/[Java
-15] & https://openjdk.java.net/projects/jdk/16/[Java 16] and their
-respective final and review features:
-
-* text blocks (final 15)
-* records (preview 15, final 16)
-* instanceof pattern matching (preview 15, final 16)
-* hidden classes (final 15)
-* sealed classes (preview 15, preview 16)
-
-For features marked as preview on a given JDK, you need to compile with
-`ajc --enable-preview` and run with `java --enable-preview on` that JDK.
-
-Please note, that you cannot run code compiled with preview features on
-any other JDK than the one used for compilation. For example, records
-compiled with preview on JDK 15 cannot be used on JDK 16 without
-recompilation. This is a JVM limitation unrelated to AspectJ. Also, e.g.
-sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16. You
-still need to recompile, no matter what.
-
-You can find some sample code in the AspectJ test suite under the
-respective AspectJ version in which the features were first supported
-(possibly as JVM preview features):
-
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features195/textblock[AspectJ
-1.9.5: text blocks]
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features196/java14[AspectJ
-1.9.6: records, instanceof patterns]
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features197/java15[AspectJ
-1.9.7: hidden classes, sealed classes]
-
-=== Using LTW on Java 16+
-
-Please note that if you want to use load-time weaving on Java 16+, the
-weaving agent collides with https://openjdk.java.net/jeps/396[JEP 396
-(Strongly Encapsulate JDK Internals by Default)]. Therefore, you need to
-set the JVM parameter `--add-opens java.base/java.lang=ALL-UNNAMED` in
-order to enable aspect weaving. This is due to the fact that the weaver
-uses internal APIs for which we have not found an adequate replacement
-yet when defining classes in different classloaders.
-
-=== Organisational and internal changes
-
-For AspectJ 1.9.7, we implemented a lot of internal changes concerning
-the build and release process, most of which are not visible in the
-product itself but will help us to more easily maintain and release the
-product in the future and more easily on-boarding new developers or
-contributors. For example:
-
-* The main repository has been moved to
-https://github.com/eclipse/org.aspectj[GitHub], i.e. you can open bug
-reports, feature requests and pull requests there now.
-* The Maven build has been improved, i.e. it is now easier to build and
-contribute to the product. Developers can just import the Maven project
-and no longer depend on Eclipse to build and test AspectJ, but can e.g.
-also use IntelliJ IDEA.
-* Continuous integration builds now run on GitHub for different JDK
-versions, also for pull requests. I.e. both maintainers and contributors
-get to know if their changes break any tests.
-* We can build releases and deploy them directly to Sonatype OSSRH
-(snapshots) or Maven Central (releases) with Maven now, i.e. it should
-be much easier in the future to publish development versions in order to
-enable users to re-test fixed bugs or try new features.
-* All tests are portable now, i.e. they correctly run on Windows, too.
-This enables developers and contributors to make a choice if they want
-to work on Linux or on Windows.
-
-=== Other changes and bug fixes
-
-* Remove legacy JRockit support.
-* Support Windows 10 and Windows Server 2016/2019 in installer. Those
-versions were not detected until now, which led to bogus Windows batch
-files forwarding only 9 AJC parameters to the Java process via `%1 %2 %3
-%4 %5 %6 %7 %8 %9` instead of `%*`.
-* AJdoc (AspectJ's javadoc generator add-on for aspects) now supports
-the JDK 16 javadoc generator.
-* Fix `serialVersionUID` initialization for Java 9+
-* AJC (AspectJ Compiler) usage texts sometimes used to be printed twice
-and they were printed too often, e.g. on top of every compile error.
-This has been fixed. Furthermore, the partly outdated usage text is now
-basically the same as ECJ (Eclipse Java Compiler), which AJC is a fork
-of, plus AspectJ-specific additions which are added during runtime.
-* Source and javadoc JARs distributed together with the AspectJ
-artifacts on Maven Central are now more accurate and more complete with
-regard to what is included (ASM, JDT Core) and how package names have
-been relocated.
-* Fix sample code formatting issues (indentation) throughout the
-documentation.
diff --git a/docs/dist/doc/README-198.adoc b/docs/dist/doc/README-198.adoc
deleted file mode 100644
index 29b04ef7c..000000000
--- a/docs/dist/doc/README-198.adoc
+++ /dev/null
@@ -1,86 +0,0 @@
-== AspectJ 1.9.8
-
-_© Copyright 2022 Contributors. All rights reserved._
-
-_Release info: 1.9.8 available 11-Feb-2022_
-
-Please note, that Bugzilla for issue management is deprecated, and new issues should be filed as
-https://github.com/eclipse/org.aspectj/issues/new[GitHub issues]. The list of issues addressed for 1.9.8 can be found
-https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.8[here for Bugzilla] and
-https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.8[here for GitHub issues].
-
-=== New features
-
-AspectJ 1.9.8 supports https://openjdk.java.net/projects/jdk/17/[Java 17] and its final and review features, such as:
-
-* Sealed classes (final in Java 17, previews in Java 15, 16 and AspectJ 1.9.7)
-* Pattern matching for `switch`
-
-=== Improvements
-
-The `--release N` compiler option for correct cross-compilation to previous JDK bytecode + API versions is now supported
-by AJC. Previously, the option existed (inherited by ECJ) but did not work correctly.
-
-The following new properties can improve performance, e.g. Spring start-up time:
-
-* `org.aspectj.apache.bcel.useSingleRepositoryInstance`
-* `org.aspectj.apache.bcel.useUnavailableClassesCache`
-* `org.aspectj.apache.bcel.ignoreCacheClearRequests`
-
-For now, they all default to `false` for backward compatibility. This might change in a future Aspect release, if user
-feedback is positive and no negative side effects are found. Please try using them as much as you can and report back
-questions (to the AspectJ users mailing list) or problems (as a GitHub issue), if any. Thanks to Stefan Starke for his
-contribution. See also https://github.com/eclipse/org.aspectj/pull/37[PR #37].
-
-=== Code examples
-
-You can find some sample code in the AspectJ test suite under the respective AspectJ version in which the features were
-first supported (possibly as JVM preview features):
-
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features198/compiler_release[Cross-compilation to legacy JDK]:
-  An example class which only works correctly on JDK 8 when compiled with `--release 8` due to API changes in
-  the JDK. Simply `-source 8 -target 8` would not be enough in this case.
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features198/java17[Pattern matching for `switch`]
-
-=== Other changes and bug fixes
-
-* The AspectJ compiler `ajc` (contained in the `aspectjtools` library) no longer works on JDKs 8 to 10. The minimum
-  compile-time requirement is now JDK 11 due to upstream changes in the Eclipse Java Compiler (subset of JDT Core),
-  which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling plain
-  Java code or using plain Java ITD constructs which do not require the AspectJ runtime `aspectjrt`, but the compiler
-  itself needs JDK 11+. Just like in previous AspectJ versions, both the runtime `aspectjrt` and the load-time weaver
-  `aspectjweaver` still only require JRE 8+.
-* Document build profiles and properties in _docs/developer/BUILD.md_
-* Add a guide for setting up an AspectJ development environment in _docs/developer/IDE.md_
-* Fix https://github.com/eclipse/org.aspectj/issues/105[issue #105]: Compilation fails when using an aspect library via
-  `-aspectpath` in combination with introducing an annotation via ITD. This was broken since version 1.9.5 and fixed in
-  1.9.8.RC3.
-* Fix https://github.com/eclipse/org.aspectj/issues/68[issue #68]: Correctly process class files containing
-  https://openjdk.java.net/jeps/309[dynamic class-file constants (JEP 309)], which were introduced in Java 11 and broken
-  in AspectJ ever since their introduction in 1.9.2. Java itself currently does not use "condy" and neither do other
-  widespread JVM languages. Byte code engineering libraries like ASM or Byte Buddy and some instrumentation tools like
-  JaCoCo can however produce condy code. Therefore, in order to create a regression test, we actually had to
-  https://github.com/eclipse/org.aspectj/blob/de63b63d/tests/bugs198/github_68/Generator.java#L50-L61[craft a condy
-  class with ASM].
-* Thanks to Andrey Turbanov for several clean code contributions and to Dmitry Mikhaylov for fixing a potential
-  concurrency problem.
-
-=== AspectJ usage hints
-
-==== Use LTW on Java 16+
-
-Please note that if you want to use load-time weaving on Java 16+, the weaving agent collides with
-https://openjdk.java.net/jeps/396[JEP 396 (Strongly Encapsulate JDK Internals by Default)]. Therefore, you need to set
-the JVM parameter `--add-opens java.base/java.lang=ALL-UNNAMED` in order to enable aspect weaving. This is due to the
-fact that the weaver uses internal APIs for which we have not found an adequate replacement yet when defining classes
-in different classloaders.
-
-==== Compile with Java preview features
-
-For features marked as preview on a given JDK, you need to compile with `ajc --enable-preview` and run with
-`java --enable-preview` on that JDK.
-
-Please note, that you cannot run code compiled with preview features on any other JDK than the one used for compilation.
-For example, records compiled with preview on JDK 15 cannot be used on JDK 16 without recompilation. This is a JVM
-limitation unrelated to AspectJ. Also, e.g. sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16. You still
-need to recompile, no matter what.
diff --git a/docs/dist/doc/README-199.adoc b/docs/dist/doc/README-199.adoc
deleted file mode 100644
index 900f70b89..000000000
--- a/docs/dist/doc/README-199.adoc
+++ /dev/null
@@ -1,94 +0,0 @@
-== AspectJ 1.9.9.1
-
-_© Copyright 2022 Contributors. All rights reserved._
-
-_Release info: 1.9.9.1 available 31-Mar-2022_
-
-Bugfix release for some compiler options related to the Java Platform Module System (JPMS) which were not working, most
-importantly `--add-modules`, `--add-exports` and `--add-reads`. See
-https://github.com/eclipse/org.aspectj/issues/145[issue #145].
-
-This probably was broken for a long time. AspectJ still is not boasting extensive JPMS support or test coverage, but
-this improvement seems substantial enough to justify a minor release, instead of keeping users waiting for the next
-regular release.
-
-== AspectJ 1.9.9
-
-_© Copyright 2022 Contributors. All rights reserved._
-
-_Release info: 1.9.9 available 24-Mar-2022_
-
-Please note that Bugzilla for issue management is deprecated and new issues should be filed as
-https://github.com/eclipse/org.aspectj/issues/new[GitHub issues]. The list of issues addressed for 1.9.9 can be found
-here:
-
-* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.9[GitHub 1.9.9]
-* https://github.com/eclipse/org.aspectj/issues?q=is%3Aissue+is%3Aclosed++milestone%3A1.9.9.1[GitHub 1.9.9.1]
-* https://bugs.eclipse.org/bugs/buglist.cgi?bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED&f0=OP&f1=OP&f3=CP&f4=CP&j1=OR&list_id=16866879&product=AspectJ&query_format=advanced&target_milestone=1.9.9[Bugzilla 1.9.9]
-
-=== New features
-
-AspectJ 1.9.9 supports https://openjdk.java.net/projects/jdk/18/[Java 18] and its final and preview features, such as:
-
-* Pattern matching for `switch` (preview 2)
-
-=== Improvements
-
-In annotation style aspects, asynchronous `proceed()` calls in `@Around` advice now works in threads created from within
-the advice. Previously, this was only working in native syntax aspects. There is still a limitation with regard to
-asynchronous proceed, if you do not create the thread in the advice but want to use e.g. an `ExecutorService` with its
-own thread pool. This still is not working in annotation style aspects, only in native syntax ones.
-
-See https://github.com/eclipse/org.aspectj/issues/128[issue #128] and
-https://github.com/eclipse/org.aspectj/pull/132[pull request #132] for more details.
-
-=== Code examples
-
-You can find some sample code in the AspectJ test suite under the respective AspectJ version in which the features were
-first supported (possibly as JVM preview features):
-
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features198/java17[Pattern matching for switch, preview 1]
-* https://github.com/eclipse/org.aspectj/tree/master/tests/features199/java18[Pattern matching for switch, preview 2]
-* https://github.com/eclipse/org.aspectj/tree/master/tests/bugs199/github_128[Asynchronous proceed in native vs.
-  annotation style syntax]
-
-=== Other changes and bug fixes
-
-* Fix a bug which led to ``NullPointerException``s, if too many JAR archives were on the classpath. Too many here means
-  the value of system property `org.aspectj.weaver.openarchives` (1,000 by default). The AspectJ compiler is meant to
-  close archives upon cache exhaustion and then re-open them, if it needs them again later. Re-opening was broken, but
-  now the compiler works reliably even for cache sizes as small as 20. See
-  https://github.com/eclipse/org.aspectj/issues/125[issue #125].
-* Improvements for `if()` pointcuts in annotation syntax, see issues
-  https://github.com/eclipse/org.aspectj/issues/115[#115], https://github.com/eclipse/org.aspectj/issues/120[#120],
-  https://github.com/eclipse/org.aspectj/issues/122[#122].
-* Thanks to Andrey Turbanov for several clean code contributions.
-
-=== AspectJ usage hints
-
-==== AspectJ compiler build system requirements
-
-Since 1.9.8, the AspectJ compiler `ajc` (contained in the `aspectjtools` library) no longer works on JDKs 8 to 10. The
-minimum compile-time requirement is now JDK 11 due to upstream changes in the Eclipse Java Compiler (subset of JDT
-Core), which AspectJ is a fork of. You can still compile to legacy target versions as low as Java 1.3 when compiling
-plain Java code or using plain Java ITD constructs which do not require the AspectJ runtime `aspectjrt`, but the
-compiler itself needs JDK 11+. Just like in previous AspectJ versions, both the runtime `aspectjrt` and the load-time
-weaver `aspectjweaver` still only require JRE 8+.
-
-==== Use LTW on Java 16+
-
-Please note that if you want to use load-time weaving on Java 16+, the weaving agent collides with
-https://openjdk.java.net/jeps/396[JEP 396 (Strongly Encapsulate JDK Internals by Default)]. Therefore, you need to set
-the JVM parameter `--add-opens java.base/java.lang=ALL-UNNAMED` in order to enable aspect weaving. This is due to the
-fact that the weaver uses internal APIs for which we have not found an adequate replacement yet when defining classes
-in different classloaders.
-
-==== Compile with Java preview features
-
-For features marked as preview on a given JDK, you need to compile with `ajc --enable-preview` and run with
-`java --enable-preview` on that JDK.
-
-Please note, that you cannot run code compiled with preview features on any other JDK than the one used for compilation.
-For example, records compiled with preview on JDK 15 cannot be used on JDK 16 without recompilation. This is a JVM
-limitation unrelated to AspectJ. Also, e.g. sealed classes are preview-1 on JDK 15 and preview-2 on JDK 16. You still
-need to recompile, no matter what.
diff --git a/docs/dist/doc/changes.adoc b/docs/dist/doc/changes.adoc
index 9034ac0d1..5b08e48ae 100644
--- a/docs/dist/doc/changes.adoc
+++ b/docs/dist/doc/changes.adoc
@@ -12,7 +12,7 @@ _© Copyright 1998-2002 Palo Alto Research Center Incorporated
 * xref:#_1_2_1[1.2.1] (released 2004-10)
 * xref:#_1_2[1.2] (released 2004-05)
 * xref:#_1_1_1[1.1.1] (released 2003-09)
-* 1.1.0 (released 2003-06-06) See xref:README-11.adoc#readme-1_1[1.1.0 release notes].
+* 1.1.0 (released 2003-06-06) See xref:README-1.1.adoc#readme-1_1[1.1.0 release notes].
 * xref:#_1_0_6[1.0.6] (released 2002-07-24)
 ** xref:#_1_0_6compiler[Compiler]
 ** xref:#_1_0_6ajde[AJDE]
diff --git a/docs/dist/doc/porting.adoc b/docs/dist/doc/porting.adoc
index 0bda1cf3b..31f3016ae 100644
--- a/docs/dist/doc/porting.adoc
+++ b/docs/dist/doc/porting.adoc
@@ -17,7 +17,7 @@ _© Copyright 1998-2002 Palo Alto Research Center Incorporated,
 [[pre-1_2]]
 === Porting pre-1.2 code to AspectJ 1.2
 
-README-12.html contains a discussion of the changes between 1.1 and 1.2.
+README-1.2.html contains a discussion of the changes between 1.1 and 1.2.
 The key points are:
 
 *The default AspectJ compiler compliance level is now 1.4* (whereas in
@@ -192,7 +192,7 @@ https://bugs.eclipse.org/bugs/show_bug.cgi?id=59921[59921].
 [[pre-1_1]]
 === Porting pre-1.1 code to AspectJ 1.1
 
-README-11.html contains a discussion of the language changes from 1.0 to
+README-1.1.html contains a discussion of the language changes from 1.0 to
 1.1. The high points:
 
 The `call(..)` pointcut designator is now implemented only at the call
@@ -201,14 +201,14 @@ the callee side. So in 1.0 if you compiled a pointcut using `call(..)`
 but only passed the compiler the code for the target of the call, the
 pointcut could be implemented. This is not true for 1.1. To fix this,
 use `execution(..)` in place of `call(..)`, or include all calling
-clients in the compile. (xref:README-11.adoc#NO_CALLEE_SIDE_CALL[more
+clients in the compile. (xref:README-1.1.adoc#NO_CALLEE_SIDE_CALL[more
 info])
 
 Type-patterns are no longer permitted for the defining type of
 inter-type declarations. Replace the pattern with a type. In many cases,
 you can declare members on an interface type, and then declare that the
 types picked out by the type-pattern implement have the interface as
-their parent. (xref:README-11.adoc#SINGLE_INTERCLASS_TARGET[more info])
+their parent. (xref:README-1.1.adoc#SINGLE_INTERCLASS_TARGET[more info])
 
 Type-patterns are no longer permitted when specifying `declare soft`.
 Replace the pattern with a literal type.
@@ -216,7 +216,7 @@ Replace the pattern with a literal type.
 Wildcards patterns (`foo..*`) are no longer permitted for `this()`,
 `target()`, or `args()`. Replace the pattern with a literal type or with
 a subtype wildcard (`Type+`).
-(xref:README-11.adoc#INSTANCEOF_ON_WILD[more info])
+(xref:README-1.1.adoc#INSTANCEOF_ON_WILD[more info])
 
 Conflicts will be reported for no-argument constructors generated by
 compilers when no constructor is defined for a class. That means the
@@ -234,14 +234,14 @@ One fix is to declare a non-conflicting constructor by adding arguments
 (or defining a constructor in the target class); a better fix might be
 to do the work of the declared constructor in advice on the
 initialization join point for the object.
-(xref:README-11.adoc#DEFAULT_CONSTRUCTOR_CONFLICT[more info])
+(xref:README-1.1.adoc#DEFAULT_CONSTRUCTOR_CONFLICT[more info])
 
 The pointcut designators `within()` and `withincode()` will not pick out
 code within the lexical extent of method-local and anonymous inner types
 (because these are not represented as such in bytecode form). Because
 `within` forms specify staticly-determinable pointcuts, they might be
 used in declare error or declare warning statements, which might produce
-different results. (xref:README-11.adoc#WITHIN_MEMBER_TYPES[more info])
+different results. (xref:README-1.1.adoc#WITHIN_MEMBER_TYPES[more info])
 
 The compiler will report an error that the form
 `aspect {name} dominates {list}...` is no longer supported. It has been
@@ -252,17 +252,17 @@ replaced by a new declare statement:
 declare precedence : {name} {list}...
 ....
 
-(xref:README-11.adoc#ASPECT_PRECEDENCE[more info])
+(xref:README-1.1.adoc#ASPECT_PRECEDENCE[more info])
 
 The field set join point now has a return type of `void`. Compiling
 programs using around advice on these join points might cause errors
 unless the return type of the around advice and the result of any
 proceed() call is `Object` or `void`.
-(xref:README-11.adoc#VOID_FIELD_SET[more info])
+(xref:README-1.1.adoc#VOID_FIELD_SET[more info])
 
 The compiler cannot implement after or around advice for the handler PCD
 because the end of exception handlers is ambiguous in bytecode. Try to
-use before advice. (xref:README-11.adoc#AFTER_HANDLER[more info])
+use before advice. (xref:README-1.1.adoc#AFTER_HANDLER[more info])
 
 [[pre-1_0_4]]
 === Porting pre-1.0.4 code
diff --git a/docs/faq/faq.adoc b/docs/faq/faq.adoc
index 6db5afa34..a5a76e804 100644
--- a/docs/faq/faq.adoc
+++ b/docs/faq/faq.adoc
@@ -3308,10 +3308,10 @@ significant releases (1.0, 1.1).
 |Version |Description
 
 |AspectJ 1.5 |Upgrade to support Java 5 language and much better
-load-time weaving. See README-150.html for more details.
+load-time weaving. See README-1.5.0.html for more details.
 
 |AspectJ 1.1 |A few language changes and clarifications; bytecode
-weaving and incremental compilation. See README-11.html for more detail.
+weaving and incremental compilation. See README-1.1.html for more detail.
 
 |AspectJ 1.0 |Many language changes, fixes, cleanup and clarifications,
 some significant.
diff --git a/docs/index.adoc b/docs/index.adoc
index 3d131db57..34dc1c780 100644
--- a/docs/index.adoc
+++ b/docs/index.adoc
@@ -86,32 +86,32 @@ each join point. See also the xref:weaver-api/index.html[Weaver API]
 language, tools, and project.
 
 |README's |Changes and porting guide for AspectJ
-xref:dist/doc/README-1921.adoc[1.9.21],
-xref:dist/doc/README-1920.adoc[1.9.20 and 1.9.20.1], xref:dist/doc/README-1919.adoc[1.9.19],
-xref:dist/doc/README-199.adoc[1.9.9 and 1.9.9.1], xref:dist/doc/README-198.adoc[1.9.8],
-xref:dist/doc/README-197.adoc[1.9.7], xref:dist/doc/README-196.adoc[1.9.6],
-xref:dist/doc/README-195.adoc[1.9.5], xref:dist/doc/README-194.adoc[1.9.4],
-xref:dist/doc/README-193.adoc[1.9.3], xref:dist/doc/README-192.adoc[1.9.2],
-xref:dist/doc/README-191.adoc[1.9.1], xref:dist/doc/README-190.adoc[1.9.0],
-xref:dist/doc/README-1811.adoc[1.8.11], xref:dist/doc/README-1810.adoc[1.8.10],
-xref:dist/doc/README-189.adoc[1.8.9], xref:dist/doc/README-188.adoc[1.8.8],
-xref:dist/doc/README-187.adoc[1.8.7], xref:dist/doc/README-186.adoc[1.8.6],
-xref:dist/doc/README-185.adoc[1.8.5], xref:dist/doc/README-184.adoc[1.8.4],
-xref:dist/doc/README-183.adoc[1.8.3], xref:dist/doc/README-182.adoc[1.8.2],
-xref:dist/doc/README-181.adoc[1.8.1], xref:dist/doc/README-180.adoc[1.8.0],
-xref:dist/doc/README-174.adoc[1.7.4], xref:dist/doc/README-173.adoc[1.7.3],
-xref:dist/doc/README-172.adoc[1.7.2], xref:dist/doc/README-171.adoc[1.7.1],
-xref:dist/doc/README-170.adoc[1.7.0], xref:dist/doc/README-1612.adoc[1.6.12],
-xref:dist/doc/README-1611.adoc[1.6.11], xref:dist/doc/README-1610.adoc[1.6.10],
-xref:dist/doc/README-169.adoc[1.6.9], xref:dist/doc/README-168.adoc[1.6.8],
-xref:dist/doc/README-167.adoc[1.6.7], xref:dist/doc/README-166.adoc[1.6.6],
-xref:dist/doc/README-165.adoc[1.6.5], xref:dist/doc/README-164.adoc[1.6.4],
-xref:dist/doc/README-163.adoc[1.6.3], xref:dist/doc/README-162.adoc[1.6.2],
-xref:dist/doc/README-161.adoc[1.6.1], xref:dist/doc/README-160.adoc[1.6.0],
-xref:dist/doc/README-154.adoc[1.5.4], xref:dist/doc/README-153.adoc[1.5.3],
-xref:dist/doc/README-152.adoc[1.5.2], xref:dist/doc/README-151.adoc[1.5.1],
-xref:dist/doc/README-150.adoc[1.5.0], xref:dist/doc/README-121.adoc[1.2.1],
-xref:dist/doc/README-12.adoc[1.2.0], xref:dist/doc/README-11.adoc[1.1], and
+xref:dist/doc/README-1.9.21.adoc[1.9.21],
+xref:dist/doc/README-1.9.20.adoc[1.9.20 and 1.9.20.1], xref:dist/doc/README-1.9.19.adoc[1.9.19],
+xref:dist/doc/README-1.9.9.adoc[1.9.9 and 1.9.9.1], xref:dist/doc/README-1.9.8.adoc[1.9.8],
+xref:dist/doc/README-1.9.7.adoc[1.9.7], xref:dist/doc/README-1.9.6.adoc[1.9.6],
+xref:dist/doc/README-1.9.5.adoc[1.9.5], xref:dist/doc/README-1.9.4.adoc[1.9.4],
+xref:dist/doc/README-1.9.3.adoc[1.9.3], xref:dist/doc/README-1.9.2.adoc[1.9.2],
+xref:dist/doc/README-1.9.1.adoc[1.9.1], xref:dist/doc/README-1.9.0.adoc[1.9.0],
+xref:dist/doc/README-1.8.11.adoc[1.8.11], xref:dist/doc/README-1.8.10.adoc[1.8.10],
+xref:dist/doc/README-1.8.9.adoc[1.8.9], xref:dist/doc/README-1.8.8.adoc[1.8.8],
+xref:dist/doc/README-1.8.7.adoc[1.8.7], xref:dist/doc/README-1.8.6.adoc[1.8.6],
+xref:dist/doc/README-1.8.5.adoc[1.8.5], xref:dist/doc/README-1.8.4.adoc[1.8.4],
+xref:dist/doc/README-1.8.3.adoc[1.8.3], xref:dist/doc/README-1.8.2.adoc[1.8.2],
+xref:dist/doc/README-1.8.1.adoc[1.8.1], xref:dist/doc/README-1.8.0.adoc[1.8.0],
+xref:dist/doc/README-1.7.4.adoc[1.7.4], xref:dist/doc/README-1.7.3.adoc[1.7.3],
+xref:dist/doc/README-1.7.2.adoc[1.7.2], xref:dist/doc/README-1.7.1.adoc[1.7.1],
+xref:dist/doc/README-1.7.0.adoc[1.7.0], xref:dist/doc/README-1.6.12.adoc[1.6.12],
+xref:dist/doc/README-1.6.11.adoc[1.6.11], xref:dist/doc/README-1.6.10.adoc[1.6.10],
+xref:dist/doc/README-1.6.9.adoc[1.6.9], xref:dist/doc/README-1.6.8.adoc[1.6.8],
+xref:dist/doc/README-1.6.7.adoc[1.6.7], xref:dist/doc/README-1.6.6.adoc[1.6.6],
+xref:dist/doc/README-1.6.5.adoc[1.6.5], xref:dist/doc/README-1.6.4.adoc[1.6.4],
+xref:dist/doc/README-1.6.3.adoc[1.6.3], xref:dist/doc/README-1.6.2.adoc[1.6.2],
+xref:dist/doc/README-1.6.1.adoc[1.6.1], xref:dist/doc/README-1.6.0.adoc[1.6.0],
+xref:dist/doc/README-1.5.4.adoc[1.5.4], xref:dist/doc/README-1.5.3.adoc[1.5.3],
+xref:dist/doc/README-1.5.2.adoc[1.5.2], xref:dist/doc/README-1.5.1.adoc[1.5.1],
+xref:dist/doc/README-1.5.0.adoc[1.5.0], xref:dist/doc/README-1.2.1.adoc[1.2.1],
+xref:dist/doc/README-1.2.adoc[1.2.0], xref:dist/doc/README-1.1.adoc[1.1],
 xref:dist/doc/porting.adoc[1.0].
 
 |xref:dist/doc/changes.adoc[Changes] |Changes between historical releases up to 1.6.0.
diff --git a/testing/src/test/java/org/aspectj/testing/AntSpec.java b/testing/src/test/java/org/aspectj/testing/AntSpec.java
index 07f2f10ff..303729cac 100644
--- a/testing/src/test/java/org/aspectj/testing/AntSpec.java
+++ b/testing/src/test/java/org/aspectj/testing/AntSpec.java
@@ -100,7 +100,7 @@ public class AntSpec implements ITestStep {
 
 			// On Java 16+, LTW no longer works without this parameter. Add the argument here and not in AjcTestCase::run,
 			// because even if 'useLTW' and 'useFullLTW' are not set, we might in the future have tests for weaver attachment
-			// during runtime. See also docs/dist/doc/README-187.html.
+			// during runtime. See also docs/dist/doc/README-1.8.7.html.
 			//
 			// Attention: Ant 1.6.3 under Linux neither likes "" (empty string) nor " " (space), on Windows it would not be
 			// a problem. So we use "_dummy" Java system properties, even though they pollute the command line.
diff --git a/testing/src/test/java/org/aspectj/testing/RunSpec.java b/testing/src/test/java/org/aspectj/testing/RunSpec.java
index c50b40f76..ca6c010d9 100644
--- a/testing/src/test/java/org/aspectj/testing/RunSpec.java
+++ b/testing/src/test/java/org/aspectj/testing/RunSpec.java
@@ -70,7 +70,7 @@ public class RunSpec implements ITestStep {
 				vmargs = "";
 			// On Java 16+, LTW no longer works without this parameter. Add the argument here and not in AjcTestCase::run,
 			// because even if 'useLTW' and 'useFullLTW' are not set, we might in the future have tests for weaver attachment
-			// during runtime. See also docs/dist/doc/README-187.html.
+			// during runtime. See also docs/dist/doc/README-1.8.7.html.
 			//
 			// The reason for setting this parameter for Java 9+ instead of 16+ is that it helps to avoid the JVM printing
 			// unwanted illegal access warnings during weaving in 'useFullLTW' mode, either making existing tests fail or
diff --git a/tests/bugs/seven/lint/Main.java b/tests/bugs/seven/lint/Main.java
index 4b7598beb..a302cb3d8 100644
--- a/tests/bugs/seven/lint/Main.java
+++ b/tests/bugs/seven/lint/Main.java
@@ -107,7 +107,7 @@ aspect XlintTest {
     /*
      * example for "canNotImplementLazyTjp"
      *
-     * This example is from the README-12.html. To get the warning you must
+     * This example is from the README-1.2.html. To get the warning you must
      * compile it with "-XlazyTjp"
      *
      * NOTE: The expected warnung does not appear. I don't know why.