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>
* 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) [ ]
/>
</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"
<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}"
--- /dev/null
+[[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"].
--- /dev/null
+== 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]
--- /dev/null
+== 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
--- /dev/null
+== 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.
--- /dev/null
+== 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.
--- /dev/null
+== 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.
--- /dev/null
+== 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.
--- /dev/null
+== 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)
+
+ +
+
+'''''
--- /dev/null
+== 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
+
+'''''
--- /dev/null
+== 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);
+}
+....
--- /dev/null
+== 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]
--- /dev/null
+== 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.
--- /dev/null
+== 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.
--- /dev/null
+== 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.
+
+'''''
--- /dev/null
+== 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).
+
+'''''
--- /dev/null
+== 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.
--- /dev/null
+== 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]
+
+'''''
--- /dev/null
+== 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*
--- /dev/null
+== 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]
+
+'''''
--- /dev/null
+== 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.
--- /dev/null
+== 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
+
+'''''
--- /dev/null
+== 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
+}
+....
--- /dev/null
+== 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 +
--- /dev/null
+== 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.
--- /dev/null
+== 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]
--- /dev/null
+== 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
+....
--- /dev/null
+== 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< ===
+....
--- /dev/null
+== 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.
--- /dev/null
+== 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.
--- /dev/null
+== 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.
--- /dev/null
+== 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.
--- /dev/null
+== 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.
--- /dev/null
+== 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.
--- /dev/null
+== 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]).
--- /dev/null
+== 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]
--- /dev/null
+== 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.
--- /dev/null
+== 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.
--- /dev/null
+== 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).
--- /dev/null
+== 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])
--- /dev/null
+== 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);
+ }
+}
+....
--- /dev/null
+== 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.
--- /dev/null
+== 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
--- /dev/null
+== 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.
--- /dev/null
+== 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.
--- /dev/null
+== 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
+....
--- /dev/null
+== 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.
--- /dev/null
+== 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
+....
--- /dev/null
+== 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
+....
--- /dev/null
+== 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.
--- /dev/null
+== 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.
--- /dev/null
+== 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.
+++ /dev/null
-[[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"].
+++ /dev/null
-== 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
+++ /dev/null
-== 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]
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
+++ /dev/null
-== 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)
-
- +
-
-'''''
+++ /dev/null
-== 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
-
-'''''
+++ /dev/null
-== 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);
-}
-....
+++ /dev/null
-== 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]
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
-
-'''''
+++ /dev/null
-== 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).
-
-'''''
+++ /dev/null
-== 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.
+++ /dev/null
-== 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]
-
-'''''
+++ /dev/null
-== 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*
+++ /dev/null
-== 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]
-
-'''''
+++ /dev/null
-== 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.
+++ /dev/null
-== 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
-
-'''''
+++ /dev/null
-== 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
-}
-....
+++ /dev/null
-== 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 +
+++ /dev/null
-== 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.
+++ /dev/null
-== 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]
+++ /dev/null
-== 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
-....
+++ /dev/null
-== 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< ===
-....
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
+++ /dev/null
-== 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]).
+++ /dev/null
-== 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]
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
+++ /dev/null
-== 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).
+++ /dev/null
-== 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])
+++ /dev/null
-== 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);
- }
-}
-....
+++ /dev/null
-== 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.
+++ /dev/null
-== 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
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
+++ /dev/null
-== 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
-....
+++ /dev/null
-== 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.
+++ /dev/null
-== 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
-....
+++ /dev/null
-== 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
-....
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
+++ /dev/null
-== 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.
* 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]
[[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
[[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
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.
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
(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
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
|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.
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.
// 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.
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
/*
* 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.
projects / aspectj.git / commitdiff