From 97915cc7bf880cc537e338c7d764bce646183f8a Mon Sep 17 00:00:00 2001
From: jhugunin
declare dominates
is now written
+ declare precedence
. This is incompatible with
+ previous 1.1betaX releases, but is completely compatibile with
+ 1.0 where this feature wasn't available at all.This document begins with short descriptions of changes from the @@ -104,7 +108,7 @@ available from individual SourceForge projects.
declare
- dominates
, that is intended to replace the "dominates"
+ precedence, that is intended to replace the "dominates"
clause on aspects. ..
wildcard is supported in the args
- PCD. But some features of the 1.0 compiler are not supported in the @@ -768,7 +764,7 @@ available from individual SourceForge projects.
AspectJ 1.1 has a new declare form:
-declare dominates ":" TypePatternList ";" +declare precedence ":" TypePatternList ";"This is used to declare advice ordering constraints on join @@ -777,27 +773,27 @@ available from individual SourceForge projects.
(2) the Logging aspect (and any aspect that extends it) should dominate all non-security aspects, can be expressed by: -declare dominates: *..*Security*, Logging+, *; +declare precedence: *..*Security*, Logging+, *;In the TypePatternList, the wildcard * means "any type not matched - by another type in the declare dominates".
+ 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 decare dominates, so:
+ TypePattern in a single decare precedence, so: -declare dominates: A, B, A ; // error +declare precedence: A, B, A ; // error-However, multiple declare dominates forms may legally have this - kind of circularity. For example, each of these declare dominates is +
However, multiple declare precedence forms may legally have this + kind of circularity. For example, each of these declare precedence is perfectly legal:
-declare dominates: B, A; - declare dominates: A, B; +declare precedence: B, A; + declare precedence: A, B;And a system in which both constraints are active may also be @@ -846,7 +842,7 @@ available from individual SourceForge projects.
itself. In AspectJ 1.1, we can express that constraint with a simple: -declare dominates: MyLogging, MyProfiling; +-declare precedence: MyLogging, MyProfiling;Changing order of advice for sub-aspects
@@ -873,7 +869,7 @@ available from individual SourceForge projects. }This no longer works in AspectJ 1.1, since declare dominates only +
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.
@@ -953,11 +949,7 @@ available from individual SourceForge projects.Limitations for beta
-Some changes to classes should force re-weaving, but are not - noticed
- -Inter-type declarations, declare parents are not tracked - correctly
+This new functionality is still only lightly tested.
-XnoWeave, a compiler option to suppress weaving
@@ -987,14 +979,6 @@ available from individual SourceForge projects. found will be enabled during the compilation. The binary forms of this aspects will be untouched. -Inlining around advice
- -In the beta release of the compiler, around advice was - implemented in the safest way for all uses of around advice. However, - many (if not most) case of around advice do not involve, for example, - inner classes capturing proceed, and can (and will) be implemented in - more efficient styles.
-Callee-side call join points
@@ -1176,7 +1160,7 @@ available from individual SourceForge projects.No exception checking during - weaving in 1.1beta2
+ weaving in 1.1beta3
Advice that has an explicit throws clause needs to have that throws clause checked during weaving for each join point that is @@ -1377,9 +1361,7 @@ available from individual SourceForge projects.
Though 1.1beta2 does not have code inlining turned on, we expect
- that the final release will have inlining on for many cases of around
- advice. Therefore, we are supporting the -XnoInline
+
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.
--
2.39.5