Generics in AspectJ 5

AspectJ 5 provides full support for all of the Java 5 language features, including generics. Any legal Java 5 program is a legal AspectJ 5 progam. In addition, AspectJ 5 provides support for generic and parameterized types in pointcuts, inter-type declarations, and declare statements. Parameterized types may freely be used within aspect members, and support is also provided for generic abstract aspects.

Matching generic and parameterized types in type patterns

The foundation of AspectJ's support for generic and parameterized types in aspect declarations is the extension of type pattern matching to allow matching against generic and parameterized types.

The type pattern "Foo" matches all types named Foo, whether they be simple types, generic types, or parameterized types. So for example, Foo, Foo<T>, and Foo<String>will all be matched.

AspectJ 5 also extends the specification of type patterns to allow explicit matching of generic and parameterized types by including one or more type parameter patterns inside angle braces (< >) immediately after the type pattern. For example, List<String>

  	  	TypePattern := SimpleTypePattern |
  	  	               '!' TypePattern |
  	  	               '(' AnnotationPattern? TypePattern ')'
  	  	               TypePattern '&&' TypePattern |
  	  	               TypePattern '||' TypePattern |
  	  	               TypePattern '<' TypeParameterPatternList '>'
  	  	               
  	  	TypeParameterPatternList ::= TypeParameterPattern (',' TypeParameterPattern)*
  	  	
  	  	TypeParameterPattern ::= TypePattern |
  	  	                                    '?' TypeBoundPattern?
  	  	                                    
  	  	TypeBoundPattern ::= 'extends' TypePattern AdditionalBoundPatternList? |
  	  	                               'super' TypePattern AdditionalBoundPatternList?
  	  	                     
  	  	AdditionalBoundPatternList ::= AdditionalBoundPattern AdditionalBoundPatternList |
  	  	                                         AdditionalBoundPattern
  	  	                               
  	  	AdditionalBoundPattern ::= '&' TypePattern 
  	  	
		

A simple identifier (such as String) occuring in a type parameter list will be treated as a type name unless a type variable of that name is in scope (declaring type variables is covered later). The type pattern List<E> will result in an "invalid absolute type name" warning if no type E is in scope (declared in the default package, or imported in the compilation unit) and no declaration of E as a type variable is in scope either.

Some simple examples of type patterns follow:

List<String>

Matches the parameterized type List<String>

List<? extends Number>

Matches the parameterized type List<? extends Number>

List<E>

Outside of a scope in which Eis defined as a type variable, this pattern matches the parameterized type List<E>. If E is not a type then an invalidAbsoluteTypeName xlint warning will be issued.

In a scope in which E is defined as a type variable, this pattern matches the generic type List<E>. The type parameter name does not have to match the name used in the declaration of List, but the bounds must match. This pattern also matches any parameterization of List that satisfies the bounds of the type variable (for example, List<String>).

The *, +, and .. wildcards may be used in type patterns matching against generic and parameterized types (just as in any other type pattern). The + wildcard matches all subtypes. Recalling the discussion on subtypes and supertypes in the previous section, note that the pattern List<Number>+ will match List<Number> and LinkedList<Number>, but not List<Double>. To match lists of any number type use the pattern List<Number+> which will match List<Number>, List<Double>, List<Float> and so on.

The generics wildcard ? is considered part of the signature of a parameterized type, and is not used as an AspectJ wildcard in type matching. For example:

List<*>

Matches any generic or parameterized Listtype (List<String>, List<Integer> and so on) with a single type parameter.

List<?>

Matches the parameterized type List<?> (and does not match List<String>, List<Integer> and so on)

List<? extends Number+>

Matches List<? extends Number>, List<? extends Double>, and so on, but does not match List<Double>.

Signature patterns

Now that we understand how to write type patterns that match generic and parameterized types, it is time to look at how these can be utilized to match member declarations by using signature patterns.

To match members declared in generic types and making use of type variables defined in those types (for example interface Foo<T> { public T doSomething(); } use a signature pattern of the form:

      	X Foo<X>.doSomething()
		

This assumes a scope in which X is declared as a type variable. As with type patterns, the name of the type variable does not have to match the name used in the member declaration, but the bounds must match. For example, if the interface was declared as Foo<T extends Number> then the signature pattern would be: X Foo<X extends Number>.doSomething().

T Util<T extends Number,S>.someFunction(List<S>)

Matches the method someFunction in a generic type Util with two type parameters, the first type parameter having an upper bound of Number.

LinkedList<E>.new()

Matches the no-argument constructor of the generic type LinkedList.

Matching a field with a generic type works in the same way. For example:

      	T *<T>.*
		

Matches a field of the type of type parameter T in any generic type with a single unbounded type parameter (the pattern*<T>). The field may be of any name.

Matching of members of parameterized types is straightforward. For example, void List<String>.add(String) matches the add method in the parameterized type List<String>.

To match a generic method the generic method type variable declarations become part of the signature pattern. For example:

          <T> List<T> *.favourites(List<T>)
		

matches a generic method favourites declared in any type. To match a static generic method simply include the static modifier in the type pattern.

Pointcuts

In this section we discuss how type patterns and signature patterns matching on generic and parameterized types, methods, and constructors can be used in pointcut expressions. We distinguish between pointcuts that match based on static type information, and pointcuts that match based on runtime type information (this, target, args).

First however we need to address the notion of type variables and scopes. There is a convention in Java, but no requirement, that type variables are named with a single letter. Likewise it is rare, but perfectly legal, to declare a type with a single character name. Given the type pattern List<Strng>, is this a mis-spelling of the parameterized type pattern List<String> or is it a generic type pattern with one unbounded type variable Strng?. Alternatively, given the type pattern List<E>, if the type E cannot be found, is this a missing import statement or an implied type variable? There is no way for AspectJ to disambiguate in these situations without an explicit declaration of type variable names. If E is defined as a type variable, and Strng is not, then both declarations can be correctly interpreted.

Type Variables in Pointcut Expressions

The type variables in scope for a pointcut primitive are declared in a type variable list immediately following the pointcut desginator keyword. For example:

          call<T>(* Foo<T>.*(T))
		

matches a call to a method with any name (*) declared by a generic type Foo with one unbounded type parameter. The method takes one argument which is of the type of the type variable.

In contrast, the pointcut

          call(* Foo<T>.*(T))
		

matches a call to a method with any name that takes an argument of type T, where the target of the call is declared as the parameterized type Foo<T>. If there is no type T in scope, an "invalid absolute type name (T)" warning will be issued.

The type variables declaration following a pointcut designator permits only simple identifiers (e.g. <S,T> and not <S extends Number>).

A type variable declaration list can appear following any pointcut designator except for handler (Java 5 does not permit a generic class to be a direct or indirect subtype of Throwable - see JLS 8.1.2), the dynamic pointcuts this, target, args, if, cflow, cflowbelow, and the annotation pointcut designators (@args, @this, @within and so on).

Initialization and execution pointcuts

Recall that there is only ever one type for a generic type (e.g. List<E>) regardless of how many different parameterizations of that type (e.g. List<String>, List<Double>) are used within a program. For join points that occur within a type, such as execution join points, it therefore only makes sense to talk about execution join points for the generic type. Given the generic type

        public class Foo<T> {
            
          T doSomething(T toSomeT) {
             return T;
          }  
          
        }
		

then

execution<T>(T Foo<T>.doSomething(..))

matches the execution of the doSomething method in Foo.

execution(* Foo.doSomething(..))

also matches the execution of the doSomething method in Foo.

execution(T Foo.doSomething(..))

results in an "invalid absolute type name (T)" warning since T is interpreted as a type, not a type variable.

execution(String Foo<String>.doSomething(..))

results in a compilation error "no execution join points for parameterized type Foo<String>, use a generic signature instead".

Given the type declaration

        public class Bar<N extends Number> {
            
          N doSomething(N toSomeN) {
             return N;
          }  
          
        }
		

then

execution<T>(T Bar<T>.doSomething(..))

does not match the execution of Bar.doSomething since the bounds of the type parameter T in the pointcut expression do not match the bounds of the type parameter N in the type declaration.

execution<T>(T Bar<T extends Number>.doSomething(..))

matches the execution of the doSomething method in Bar.

execution<T extends Number>(T Bar<T>.doSomething(..))

results in a compilation error, since type variable bounds must be specified as part of the declaring type pattern, and not in the type variable list.

If a type implements a parameterized interface, then execution join points exist and can be matched for the parameterized interface operations within the implementing type. For example, given the pair of types:

        public interface Greatest<T> {
            T greatest(List<T> ts);  
        }
        
        public class  NumberOperations implements Greatest<Number> {
             public Number greatest(List<Number> numbers) {
                //...
             }
        }
		

then

        execution(* Greatest<Number>.*(..))
		

will match the execution of the greatest method declared in NumberOperations. However, it does not match the execution of greatest in the program below:

        public interface Greatest<T> {
            T greatest(List<T> ts);  
        }
        
        public class  NumberOperations<N extends Number> implements Greatest<N> {
             public N greatest(List<N> numbers) {
                //...
             }
        }
        
        // in some fragment of code...
        NumberOperations<Number> numOps = new NumberOperations<Number>();
        numOps.greatest(numList);
		

Since there is only one generic type, NumberOperations, which implements a generic interface. Either of the pointcut expressions execution<T>(* Greatest<T>>.*(..)) or execution<T>(* Greatest<T extends Number>>.*(..)) will match the execution of greatest in this example. Recall from chapter Join Point Signatures that a kinded pointcut primitive matches a join point if it exactly matches one of the signatures of the join point. The signatures of the execution join point for greatest in the example above are:

public N Greatest<N>.greatest(List<N>)

from the declaration in the Greatest interface, and

public N Greatest<N extends Number>.greatest(List<N>)

from the additional bounds restriction of N in the declaration of NumberOperations

Join points for staticinitialization,initialization and preinitialization only ever exist on a generic type (an interface cannot define a constructor). The expression initialization<T>(Foo<T>.new(..)) which match any initialization join point for the generic type Foo<T>, and staticinitialization<T>(Foo<T>) matches the static initialization of that same type.

The expression staticinitialization(List<String>) will result in a compilation error: there is no static initialization join point for the parameterized type List<String>. However, the expression staticinitialization(List<String>+) is legal, and will match the static initialization of any type that implements List<String>. The expression staticinitialization<T>(List<T>+) will match the static initialization join point of any type that either extends or implements the generic type List<T> or implements any parameterization of that interface.

Static scoping: within and withincode

The within and withincode pointcut designators both match the execution of join points that occur within a type or a member of a type respectively. Therefore the same considerations with respect to there only being one type for a generic type regardless of how many parameterizations of that type are used in a program apply.

The within pointcut designator can never be used in conjunction with a simple parameterized type. So

within<T>(Foo<T>)

matches all join points occurring within the generic type Foo<T>, and

within(Foo<String>)

results in a compilation error since there is no concept of a join point within a parameterized type, but

within(Foo<String>+)

matches any join point occurring within a type that implements Foo<String>.

The withincode designator is likewise normally used with a generic type, but can be used with a parameterized interface type to match join points arising from code lexically within the implementation of the interface methods in a type that implements the parameterized interface.

withincode<T>(* Foo<T>.*(..))

matches all join points arising from code lexically within a method of the generic type Foo<T>

withincode(* Foo<String>.*(..))

results in a compilation error if Foo is not an interface. If Foo is an interface then it matches all join points arising from code lexically within the implementation of the interface methods in a type that implements Foo<String>.

withincode(* Foo<String>+.*(..))

matches any join point occurring within a method of a type that implements Foo<String>.

Call, get and set pointcuts

The call, get, and set join points can occur on the client side (ie. outside of the type owning the member being called, accessed, or updated) or within the type that owns the target member. The following short program demonstrates this:

        public class Foo<T> {
        
          public T timeFor;  
          
          public Foo<T>(T aCuppa) {
                timeFor = aCuppa;      // set-site A
          }
        
          public void doThis(T t) {
            doThat(t);  // call-site A
          }    
          
          public void doThat(T t) {
             return;
          }
            
        }
        
        public class Main {
          public static void main(String[] args) {
            Foo<String> foos = new Foo<String>();
            foos.doThis("b");  //call-site B  
            foos.doThat("c");  // call-site C
            foos.timeFor = "a cuppa"; // set-site B
          }
        }
		

We have annotated the three method call sites as call-site A, call-site B, and call-site C. Call-site A is situated within the generic type Foo<T> and the call join point has signature public void Foo<T>doThat(T). The join point arising from call-site B is a client-side call join point and has the signatures public void Foo<String>doThis(String) (from the static type of foos) and public void Foo<T>doThis(T). Likewise the call join point arising from call-site C has the signatures public void Foo<String>doThat(String) (from the static type of foos) and public void Foo<T>doThat(T). A call pointcut expression matches if the signature pattern exactly matches one of the signatures of the call join point.

The signatures for get and set join points works in a similar fashion. At set-site A in the above example, the set join point has signature public T Foo<T>.timeFor. At set-site B the set join point has signatures public T Foo<T>.timeFor and public String Foo<String>.timeFor. A get or set pointcut expression matches if the signature pattern exactly matches one of the signatures of the join point.

Some examples follow:
call(* List<?>.*(..))

matches a call to any method of a List<?> (a call where the target is declared to be a List<?>). For example:

        int countItems(List<?> anyList) {
          return anyList.size();   // matched by call(* List<?>.*(..))
        }
		
call<T>(* List<T>.*(..))

matches any call to an operation defined in the generic type List<E>. This includes calls made to List<String>, List<Number>, List<? super Foo> and so on.

get<T>(T *<T extends Account>.*)

matches the get of any field defined in a generic type with one type parameter that has an upper bound of Account. The field has the type of the type parameter, and can be of any name. This pointcut expression matches both gets of the field within the declaring type, and also gets on parameterized instances of the type.

set(Account Foo<Account>.*Account)

matches the set of a field of type Account where the target is of type Foo<Account> and the field name ends with "Account". Does not match sets of any "*Account" field occurring within the Foo type itself.

call(* List<? extends Number>.add(..))

matches any call to add an element to a list of type List<? extends Number>. Does not match calls to add elements to lists of type List<Number> or List<Double> as these are distinct types.

call(* List<Number+>.add(..))

matches any call to add an element to a list of type Number or any subclass of Number. For example, List<Number>, List<Double> List<Float>. Does not match calls to add elements to lists of type List<? extends Number> as this is a distinct type.

Handler

The Java Language Specification states that a generic class may not be a direct or indirect subclass of Throwable. Therefore it is a compilation error to use a generic or parameterized type pattern in a handler pointcut expression.

Runtime type matching: this, target and args

Java 5 generics are implemented using a technique known an erasure. In particular, what gets "erased" is the ability to find out the parameterized runtime type of an instance of a generic type. You can ask if something is an instanceof List, but not if something is an instanceof List<String>

The this, target and args pointcut designators all match based on the runtime type of the appropriate object (this, target, or argument) at a join point. To match any parameterization of a generic type, simply use the raw type (type variables are not permitted with these designators). For example:

target(List)

matches any call to an instance of List (including List<String>, List<Number>, and so on.

args (List)

matches any join point with a single argument that is an instance of List.

To match specific parameterizations of a generic type, simply use the type that you require the relevant object to be an instance of inside the pointcut expression. For example: target(List<String>).

Recall that runtime tests to determine whether an object is an instance of a parameterized type are not possible due to erasure. Therefore AspectJ matching behaviour with parameterized types for this, target and args is as follows.

If it can be statically determined that a given object will always be an instance of the required type, then the pointcut expressions matches. For example, given a variable bankAccounts of type Set<BankAccount> and the pointcut expression target(Set<BankAccount>) then any call made to bankAccounts will be matched.
If it can be statically determined that a given object can never be an instance of the required type, then the pointcut expression does not match. The expression target(List<String>)will never match a call made using a variable of type List<Number> (it is not possible for a type to implement two different parameterizations of the same interface).
If an object might be an instance of the required type in some circumstances but not in others, then since it is not possible to perform the runtime test, AspectJ deems the pointcut expression to match, but issues an unchecked warning. This is analogous to the behaviour of the Java compiler when converting between raw and parameterized types. Given a variable of type List<? extends Number> and a call join point with target pointcut expression target(List<Double>) then the expression matches but with an unchecked warning. The warning can be suppressed by annotating the associated advice with either @SuppressAjWarnings or @SuppressAjWarnings("unchecked").

When using a parameterized type with the this pointcut designator then a joinpoint is unambiguously matched if and only if one or more of the following conditions hold:

the runtime type of the this object extends or implements the parameterized type. For example, class Foo implements List<String> will match this(List<String>).
The parameterized "this" type is given using a generics wildcard in the pointcut expression, and the bounds of the generic runtime type of this are such that all valid parameterizations are matched by the wildcard. For example, the pointcut expression this(List<? extends Number>) will match a this object of type class Foo<N extends Number> implements List<N>, but not an object of type class Foo<N> implements List<N>.

You've already seen some examples of using the generic wildcard ? in parameterized type patterns. Since this, target and args match using an instance of test, the generic wildcard can be useful in specifying an acceptable range of parameterized types to match. When used in the binding form, the same restrictions on operations permitted on the bound variable apply as when a method declares a parameter with a wildcard type. For example, in the advice below, it is a compilation error to attemp to add an element into the list aList.

        before(List<? extends Number> aList) : 
          execution(* org.xyz.Foo.*(..)) && args(aList) {
           aList.add(new Double(5.0d));  // Compilation error on this line
        }
		

Declaring pointcuts in generic classes

AspectJ permits pointcuts to be declared in classes as well as aspects. A pointcut defined inside a generic class may not use the type variables of the class in the pointcut expression (just as static members of a generic class may not use type variables). For example:

        public class Foo<T extends Number> {
          
          ...
          
          // Not allowed - uses T in the pointcut expression
          public pointcut fooOperationCall(T t) : 
             call(* Foo<T>.*(T)) && args(t);   
            
            
          // permitted, but recommended to use an alternate variable name in the local 
          // type variable declaration - e.g. execution<S>(...)
          public pointcut fooExecution(Number n) :
             execution<T>(* Foo<T>.*(T)) && args(n); 
        }
		

Inter-type Declarations

AspectJ 5 allows type parameters to be used in inter-type declarations - either for declaring generic methods and constructors, or for declaring members on generic types. The syntax for declaring generic methods and constructors follows the regular AspectJ convention of simply qualifying the member name with the target type.

<T extends Number> T Utils.max(T first, T second) {...}

Declares a generic instance method max on the class Util. The max method takes two arguments, first and second which must both be of the same type (and that type must be Number or a subtype of Number) and returns an instance of that type.

static <E> E Utils.first(List<E> elements) {...}

Declares a static generic method first on the class Util. The first method takes a list of elements of some type, and returns an instance of that type.

<T> Sorter.new(List<T> elements,Comparator<? super T> comparator) {...}

Declares a constructor on the class Sorter. The constructor takes a list of elements of some type, and a comparator that can compare instances of the element type.

A generic type may be the target of an inter-type declaration, used either in its raw form or with type parameters specified. If type parameters are specified, then the number of type parameters given must match the number of type parameters in the generic type declaration. Type parameter names do not have to match. For example, given the generic type Foo<T,S extends Number> then:

String Foo.getName() {...}

Declares a getName method on behalf of the raw type Foo. It is not possible to refer to the type parameters of Foo in such a declaration.

R Foo<Q, R>.getMagnitude() {...}

Declares a method getMagnitude on the generic class Foo. The method returns an instance of the type substituted for the second type parameter in an invocation of Foo.

R Foo<Q, R extends Number>.getMagnitude() {...}

Results in a compilation error since a bounds specification is not allowed in this form of an inter-type declaration (the bounds are determined from the declaration of the target type).

A parameterized type may not be the target of an inter-type declaration. This is because there is only one type (the generic type) regardless of how many different invocations (parameterizations) of that generic type are made in a program. Therefore it does not make sense to try and declare a member on behalf of (say) Foo<String>, you can only declare members on the generic type Foo<T>.

If an inter-type member is declared inside a generic aspect, then the type parameter names from the aspect declaration may be used in the signature specification of the inter-type declaration, but not as type parameter names for a generic target type. In other words the example that follows is legal:

            public abstract aspect A<T> {
              
              private T Foo.data;
              
              public T Foo.getData(T defaultValue) {
                return (this.data != null ? data : defaultValue);
              }   
                
            }
		

Whereas the following example is not allowed and will report an error that a parameterized type may not be the target of an inter-type declaration (since when the type parameter T in the aspect is subsituted with say, String, then the target of the inter-type declaration becomes Goo<String>).

            public abstract aspect A<T> {
              
              private T Goo<T>.data;
              
              public T Goo<T>.getData(T defaultValue) {
                return (this.data != null ? data : defaultValue);
              }   
                
            }
		

Declare Parents

Both generic and parameterized types can be used as the parent type in a declare parents statement (as long as the resulting type hierarchy would be well-formed in accordance with Java's sub-typing rules). Generic types may also be used as the target type of a declare parents statement: a type variable list follows the parents keyword in these cases to declare the type variables in scope. Some examples follow:

declare parents: Foo implements List<String>

The Foo type implements the List<String> interface. If Foo already implements some other parameterization of the List interface (for example, List<Integer> then a compilation error will result since a type cannot implement multiple parameterizations of the same generic interface type.

declare parents <T>: org.xyz..*<T> extends Base<T>

All generic types declared in a package beginning with org.xyz and with a single unbounded type parameter, extend the generic type Base<T>.

declare parents <T>: org.xyz..*<T> extends Base<S>

Results in a compilation error (unless S is a type) since S is not bound in the type pattern.

Declare Soft

It is an error to use a generic or parameterized type as the softened exception type in a declare soft statement. Java 5 does not permit a generic class to be a direct or indirect subtype of Throwable (JLS 8.1.2).

Parameterized Aspects

AspectJ 5 allows an abstract aspect to be declared as a generic type. Any concrete aspect extending a generic abstract aspect must extend a parameterized version of the abstract aspect. Wildcards are not permitted in this parameterization.

Given the aspect declaration:

            public abstract aspect ParentChildRelationship<P,C> {
                ...
            }
		

then

public aspect FilesInFolders extends ParentChildRelationship<Folder,File> {...

declares a concrete sub-aspect, FilesInFolders which extends the parameterized abstract aspect ParentChildRelationship<Folder,File>.

public aspect FilesInFolders extends ParentChildRelationship {...

results in a compilation error since the ParentChildRelationship aspect must be fully parameterized.

public aspect ThingsInFolders<T> extends ParentChildRelationship<Folder,T>

results in a compilation error since concrete aspects may not have type parameters.

public abstract aspect ThingsInFolders<T> extends ParentChildRelationship<Folder,T>

declares a sub-aspect of ParentChildRelationship in which Folder plays the role of parent (is bound to the type variable P).

An exception to the rule that concrete aspects may not be generic is a pertypewithin aspect, which may be declared with a single unbounded type parameter. This is discussed in the chapter on pertypewithin.

The type parameter variables from a generic aspect declaration may be used in place of a type within any member of the aspect. For example, we can declare a ParentChildRelationship aspect to manage the bi-directional relationship between parent and child nodes as follows:

            public abstract aspect ParentChildRelationship<P,C> {
                
                /**
                 * Parents contain a list of children
                 */
                private List<C> P.children;
                    
                /**
                 * Each child has a parent
                 */
                private P C.parent;

                /**
                  * Parents provide access to their children
                  */
                public List<C> P.getChildren() {
                    return Collections.unmodifiableList(children);  
                }
                
                /**
                 * A child provides access to its parent
                 */
                 public P C.getParent() {
                   return parent;
                 }
                
                /**
                 * ensure bi-directional navigation on adding a child
                 */
                public void P.addChild(C child) {
                   if (child.parent != null) {
                     child.parent.removeChild(child);
                   }
                   children.add(child);
                   child.parent = this;
                }

                /**
                 * ensure bi-directional navigation on removing a child
                 */
                public void P.removeChild(C child) {
                   if (children.remove(child)) {
                     child.parent = null;
                   }
                }

               /**
                 * ensure bi-directional navigation on setting parent
                 */
                public void C.setParent(P parent) {
                   parent.addChild(this);
                }
                
                public pointcut addingChild(P p, C c) :
                  execution(* P.addChild(C)) && this(p) && args(c);
                  
                public pointcut removingChild(P p, C c) :
                  execution(* P.removeChild(C)) && this(p) && args(c);
            }
		

Note in the above example how the type parameters P and C can be used in inter-type declarations, pointcut expressions, and any other member of the aspect type.

The example aspect captures the protocol for managing a bi-directional parent-child relationship between any two types playing the role of parent and child. In a compiler implementation managing an abstract syntax tree (AST) in which AST nodes may contain other AST nodes we could declare the concrete aspect:

            public aspect ASTNodeContainment extends ParentChildRelationship<ASTNode,ASTNode> {
                
                before(ASTNode parent, ASTNode child) : addingChild(parent, child) {
                  ...
                }
                
            }
		

As a result of this declaration, ASTNode gains members:

List<ASTNode> children
ASTNode parent
List<ASTNode>getChildren()
ASTNode getParent()
void addChild(ASTNode child)
void removeChild(ASTNode child)
void setParent(ASTNode parent)

In a system managing files and folders, we could declare the concrete aspect:

            public aspect FilesInFolders extends ParentChildRelationship<Folder,File> {
                                
            }
		

As a result of this declaration, Folder gains members:

List<File> children
List<File> getChildren()
void addChild(File child)
void removeChild(File child)

and File gains members:

Folder parent
Folder getParent()
void setParent(Folder parent)

When used in this way, the type parameters in a generic abstract aspect declare roles, and the parameterization of the abstract aspect in the extends clause binds types to those roles. This is a case where you may consider departing from the standard practice of using a single letter to represent a type parameter, and instead use a role name. It makes no difference to the compiler which option you choose of course.

            public abstract aspect ParentChildRelationship<Parent,Child> {
                
                /**
                 * Parents contain a list of children
                 */
                private List<Child> Parent.children;
                    
                /**
                 * Each child has a parent
                 */
                private Parent Child.parent;
                
                /**
                  * Parents provide access to their children
                  */
                public List<Children> Parent.getChildren() {
                    return Collections.unmodifiableList(children);  
                }
                
                /**
                 * A child provides access to its parent
                 */
                 public Parent Children.getParent() {
                   return parent;
                 }
                                
                /**
                 * ensure bi-directional navigation on adding a child
                 */
                public void Parent.addChild(Child child) {
                   if (child.parent != null) {
                     child.parent.removeChild(child);
                   }
                   children.add(child);
                   child.parent = this;
                }
         
                ...