*minimal* 1.1 porting notes gleaned mostly from 1.1 changes.

likely to be replaced with whatever Erik does.

diff --git a/docs/dist/doc/porting.html b/docs/dist/doc/porting.html
index da62411e6c9975eb2c4138d4959f900ea20230cd..ba9350b8af671d420358a4dcedb9808e4a319102 100644 (file)
--- a/docs/dist/doc/porting.html
+++ b/docs/dist/doc/porting.html
@@ -13,6 +13,7 @@ All rights reserved.
 <h1>Porting Notes</h1>
 
 <ul>
+  <li><a href="#pre-1.1">Pre-1.1 code</a></li>
   <li><a href="#pre-1.0.4">Pre-1.0.4 code</a></li>
   <li><a href="#pre-1.0rc1">Pre-1.0rc1 code</a></li>
   <li><a href="#pre-1.0beta1">Pre-1.0beta1 code</a></li>
@@ -27,6 +28,84 @@ All rights reserved.
   <li><a href="#pre07b10">Pre-0.7beta10 code</a></li>
 </ul>
 
+<h2><a name="pre-1.1">Porting pre-1.1 code to AspectJ 1.1</a></h2>
+This section applies only to developers using AspectJ 1.1.
+It lists the few 1.1 changes that might affect 1.0 programs
+at compile-time.
+These changes were made to simplify the language for 
+bytecode weaving.
+<p>There are also some changes
+in the runtime behavior of code generated by the 1.1
+compiler which might warrant rewriting code.  For information
+on that behavior and on the new features of the 1.1 language,
+see the documentation for AspectJ 1.1.
+
+
+<p>
+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.
+<!-- todo code -->
+<p>
+Type-patterns are no longer permitted when specifying
+<code>declare soft</code>.
+Replace the pattern with a literal type.  
+<!-- todo code -->
+<p>
+Wildcards patterns (<code>foo..*</code>) are no longer 
+permitted for 
+<code>this()</code>,
+<code>target()</code>, or
+<code>args()</code>.
+Replace the pattern with a literal type or
+with a subtype wildcard (<code>Type+</code>).  
+<!-- todo code -->
+<p>
+Conflicts will be reported for no-argument constructors
+generated by compilers when no constructor is defined
+for a class. That means the following code will compile
+in 1.0 but not in 1.1:
+<pre>
+class C {}
+aspect A {
+   C.new() {}  // permitted in 1.0; conflict in 1.1
+}
+</pre>
+One fix is to declare a non-conflicting constructor
+by adding arguments (or defining a constructor in the
+target class); a better fix might be to do the work of the
+declared constructor in advice on the initialization
+join point for the object.
+<p>
+The pointcut designators
+<code>within()</code> and <code>withincode()</code>
+ 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
+<code>within</code> forms specify staticly-determinable pointcuts, 
+they might be used in declare error or declare warning
+statements, which might produce different results.
+<p>
+The compiler will report a warning that
+the form <code>aspect {name} dominates {list}...</code>
+is deprecated.  It has
+been replaced by a new declare statement:
+<pre>
+declare precedence : {name} {list}...
+</pre>
+<p>
+The field set join point now has a return type of <code>void</code>.
+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 
+<code>Object</code> or <code>void</code>.
+<p>
+
+
 <h2><a name="pre-1.0.4">Porting pre-1.0.4 code</a></h2>
 
 <p>In versions of AspectJ prior to 1.0.4, the compiler was not