Actually there is a good alternative to the proposal below:

Write all code in Java using DJ and partially evaluate calls to
traverse, fetch, gather and asList when the class graph is final
and when visitors are final.

This would be independent of Aspectj but can be used with 
AspectJ.

Has much more expressiveness: we can have multiple class graph objects,
generic programming, no Java extension, etc.

-- Karl

Third alternative:
Allow in traversal specification the use of a visitor.

==================
Proposal:

We plan to integrate AspectJ and DemeterJ to make your
AspectJ programs robust to changes in the
object structure. AspectJ would become much better
to deal with traversal-related concerns: shorter and simpler
programs that are closer to the design.
We seek input from the AspectJ user community on how
to best approach the integration. A concrete proposal
follows; it has been tested by producing a prototype as follows:
We use DemeterJ to generate the traversals outside AspectJ
and because DemeterJ produces pure Java code, we can use
AspectJ to define pointcuts and advice instead of using the
DemeterJ pointcut and advice notation.
An example is at:
http://www.ccs.neu.edu/home/lieber/com3362/w02/solutions/hw2/AspectJdoesVisitors/
and you can produce your own by downloading DemeterJ.
You can run the example yourself
after downloading rt.jar from:
http://www.ccs.neu.edu/research/demeter/software/docs/

class-graph.input contains the input:
java Main < class-graph.input
runs the program which counts inheritance relationships in
simplified UML class diagrams. 

AspectJ and DemeterJ have
similar dynamic join point models (DemeterJ
a special case of AspectJ):

AspectJ				DemeterJ
points in execution of		points in execution of
user-written calls, etc.	generated method calls only.

The generated calls we plan to produce from AspectJ statements:
declare traversal t = traversal specification;

Example:
declare traversal t = from Company to Salary;
// traversal through all Salary-objects contained in Company-object

This would generate code like:

    void t(..) {
      t_domesticDivisions(..);
      t_foreignDivisions(..);
    }
    void t_domesticDivisions(..) { domesticDivisions.t(..); }
    void t_foreignDivisions(..) { foreignDivisions.t(..); }

for class

Company {
  DeptList domesticDivisions;
  DeptList foreignDivisions;
  ...
}

and so on through Departments, WorkGroups, Employees, 
down to Salary.

DemeterJ has a useful traversal specification language
that has evolved over 10 years and Doug Orleans
implemented the best implementation we have in the AP Library
http://www.ccs.neu.edu/research/demeter/AP-Library/
which is used both in DJ as well as to generate glue code
for components.

The addition 

declare traversal t = traversal specification;

to AspectJ is basically
the only one we propose as a first step (traversal specifications
are also useful for type patterns but that is planned
for later). 

We can use the advice mechanism of AspectJ to
express the code that should be executed during the traversal.
For example, to count the number of Salary objects
we could use the abstract aspect:

abstract aspect Count {
  static int total;
  pointcut init();
  pointcut counting();
  before():init() {total=0;}
  before():counting() {total++;}

  int around(): init() {
   proceed();
   return total;
  }
}

In a subaspect we would use:

pointcut init(): target(Company) && call(int countSalaries());
pointcut counting(): target(Salary) && call(void t (..));

for the traversal of counting the number Salary-objects.

countSalaries is defined in Company as:

int countSalaries() {
  this.t(..);
  return 0;
}

Should we desire to put code on a field traversal,
e.g. the domesticDivisions field, we would use:

    pointcut traversing_domesticDivisions(): 
      Target(Company) && call(void t_domesticDivisions(..));

Pros(+) and Cons(-) for AspectJ community:
+ avoid small method problem in Java code
+ code traversal-related concerns more succinctly
+ automation of traversal code which can be tricky to write manually
+ robustness to changes in class structure
+ fast traversals (faster than DJ) because the code is generated
+ pointcuts and advice get a convenient new use: to express visitors 
- one extra declare option in AspectJ
- larger class file size due to extra generated code (can be minimized
  by using typed collections like DepartmentList instead of Vector)
- can only traverse through classes for which 
  the source code is available (with DJ you can traverse
  through library code)


Pros(+) and Cons(-) for Demeter community:
+ get all the benefits of AspectJ
+ can use more general AspectJ pointcut and advice notation
  rather than the more specialized Demeter pointcut 
  and advice notation.
- The AspectJ pointcut and advice notation is more verbose than
  the DemeterJ pointcut and advice notation.
  For example:
    before(): target(Salary) && call(void t (..)) { total++; }
  is shorter in DemeterJ:
    before Salary {{total++;}}

Issues:
(1) Would you use such a capability in AspectJ?
(2) For the traversal specification language we could
use a language very close to a subset
of the XML traversal language called XPath.

This would look like
declare traversal t = Company // Salary;
instead of
declare traversal t = from Company to Salary;

Would an XPath-style language be more desirable
than the DemeterJ notation?

-- Karl