closer to actual 1.1beta3 contents

1 files changed, 19 insertions, 37 deletions

diff --git a/build/products/tools/dist/README-11.html b/build/products/tools/dist/README-11.html
index 294ab5ed8..199928bd3 100644
--- a/build/products/tools/dist/README-11.html
+++ b/build/products/tools/dist/README-11.html
@@ -44,6 +44,10 @@ bugfixes) since the 1.1beta2 release: </p>
 <ul>
   <li>The interaction between aspect instantiation and advice has been
   <a href="#ASPECT_INSTANTIATION_AND_ADVICE">clarified</a>. </li>
+  <li>The new <code>declare dominates</code> is now written 
+  <code>declare precedence</code>.  This is incompatible with
+  previous 1.1betaX releases, but is completely compatibile with
+  1.0 where this feature wasn't available at all.</li>
 </ul>
 
 <p> This document begins with short descriptions of changes from the
@@ -104,7 +108,7 @@ available from individual SourceForge projects. </p>
   <ul>
     <li><a href="#ASPECT_PRECEDENCE">New aspect precedence form</a>:
     AspectJ 1.1 has a new declare form, <code>declare
-    dominates</code>, that is intended to replace the "dominates"
+    precedence</code>, that is intended to replace the "dominates"
     clause on aspects.  </li>
 
     <li>The order of <a href="#SUPER_IFACE_INITS">initialization join
@@ -239,18 +243,10 @@ available from individual SourceForge projects. </p>
   it into this beta release: </p>
 
   <ul>
-    <li><a href="#NO_AROUND_OPTIMIZATION">Inlining around advice</a>:
-    The optimization of around advice is not turned on in the beta,
-    and so will result in slower generated code than that generated by
-    ajc 1.0.</li>
-
     <li><a href="#EXCEPTION_CHECKING">Exception checking is not
         handled completely during weaving</a></li>
 
     <li><a href="#ERROR_MESSAGES">Error messages will sometimes be scary</a></li>
-
-    <li>Only one <code>..</code> wildcard is supported in the args
-    PCD. </li>
   </ul>
   
   <p> But some features of the 1.0 compiler are not supported in the
@@ -768,7 +764,7 @@ available from individual SourceForge projects. </p>
     <p> AspectJ 1.1 has a new declare form:
     </p>
 
-    <pre>    declare dominates ":"  TypePatternList ";"
+    <pre>    declare precedence ":"  TypePatternList ";"
     </pre>
 
     <p> This is used to declare advice ordering constraints on join
@@ -777,27 +773,27 @@ available from individual SourceForge projects. </p>
     (2) the Logging aspect (and any aspect that extends it) should
     dominate all non-security aspects, can be expressed by: </p>
 
-    <pre>    declare dominates: *..*Security*, Logging+, *;
+    <pre>    declare precedence: *..*Security*, Logging+, *;
     </pre>
 
     <p> In the TypePatternList, the wildcard * means "any type not matched
-    by another type in the declare dominates".  </p>
+    by another type in the declare precedence".  </p>
 
     <h4>Various cycles</h4>
 
       <p> It is an error for any aspect to be matched by more than one
-      TypePattern in a single decare dominates, so: </p>
+      TypePattern in a single decare precedence, so: </p>
 
-      <pre>      declare dominates:  A, B, A ;  // error
+      <pre>      declare precedence:  A, B, A ;  // error
       </pre>
 
-      <p> However, multiple declare dominates forms may legally have this
-      kind of circularity.  For example, each of these declare dominates is
+      <p> However, multiple declare precedence forms may legally have this
+      kind of circularity.  For example, each of these declare precedence is
       perfectly legal:
       </p>
 
-      <pre>      declare dominates: B, A;
-      declare dominates: A, B;
+      <pre>      declare precedence: B, A;
+      declare precedence: A, B;
       </pre>
 
       <p> And a system in which both constraints are active may also be
@@ -846,7 +842,7 @@ available from individual SourceForge projects. </p>
       itself.  In AspectJ 1.1, we can express that constraint with a
       simple: </p>
 
-      <pre>      declare dominates: MyLogging, MyProfiling;
+      <pre>      declare precedence: MyLogging, MyProfiling;
       </pre>
 
     <h4>Changing order of advice for sub-aspects</h4>
@@ -873,7 +869,7 @@ available from individual SourceForge projects. </p>
       }
       </pre>
 
-      <p> This no longer works in AspectJ 1.1, since declare dominates only
+      <p> 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.
       </p>
@@ -953,11 +949,7 @@ available from individual SourceForge projects. </p>
 
     <h4>Limitations for beta</h4>
 
-    <p> Some changes to classes should force re-weaving, but are not
-    noticed</p>
-
-    <p> Inter-type declarations, declare parents are not tracked
-    correctly</p>
+    <p> This new functionality is still only lightly tested. </p>
 
   <h3><a name="XNOWEAVE">-XnoWeave, a compiler option to suppress
   weaving</a></h3>
@@ -987,14 +979,6 @@ available from individual SourceForge projects. </p>
     found will be enabled during the compilation.  The binary forms of
     this aspects will be untouched. </p>
 
-  <h3><a name="NO_AROUND_OPTIMIZATION">Inlining around advice</a></h3>
-
-    <p> 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.  </p>
-
   <h3><a name="NO_CALLEE_SIDE_CALL">Callee-side call join
   points</a></h3>
 
@@ -1176,7 +1160,7 @@ available from individual SourceForge projects. </p>
 
 
   <h3><a name="EXCEPTION_CHECKING">No exception checking during
-  weaving in 1.1beta2</a></h3>
+  weaving in 1.1beta3</a></h3>
 
     <p>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. </p>
 
   <h3><a name="XNOINLINE">The -XnoInline Option</a></h3>
 
-    <p> 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 <code>-XnoInline</code>
+    <p> The <code>-XnoInline</code>
     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.