[abc-dev] Cflow extension and small problem with polyglot

From: Bruno Harbulot <bruno.harbulot@cs.man.ac.uk>
Date: Sat Aug 20 2005 - 11:21:23 BST


Following my previous messages about the control flow pointcut, I have
experimented a bit more with the cflow constructs, and I have come
across another (minor) problem, with polyglot.

I have tried to implement a cflowlevel(X,/Pointcut/) pointcut, which
works like cflow, but only matches when the counter has the same value as X.

Here is an example of code:

public class Test {
    public void run(int counter) {
"+Thread.currentThread().hashCode()+", counter: "+counter) ;
       if (counter>0) {
          counter-- ;
          run(counter) ;

    public static void main(String[] args) {
       Test t = new Test() ;
       t.run(5) ;

public aspect TestTrace {
     pointcut executerun(): execution(void Test.run(*)) ;
     pointcut callrun(): call(void Test.run(*)) ;

     before(): callrun() && cflowlevel("2",executerun()) {
         System.out.println(" - Before callrun() &&
cflowlevel(2,executerun())") ;

Here is what it produces:
  Thread: 8187137, counter: 5
  Thread: 8187137, counter: 4
  - Before callrun() && cflowlevel(X,executerun())
  Thread: 8187137, counter: 3
  Thread: 8187137, counter: 2
  Thread: 8187137, counter: 1
  Thread: 8187137, counter: 0

The problem I have with polyglot (I thing) is that it did not allow me
to have an integer as the first parameter type for cflowlevel:

    {: Grm.parserTrace("CFLOWLEVEL pointcut");
         RESULT =

This version compiles fine, but then, when I try to write my pointcut
like "callrun() && cflowlevel(2,executerun())" (with 2 as an integer
literal), I get the following error:
   TestTrace.aj:9: Illegal character "2"
   TestTrace.aj:9: Syntax error.

It works if I use a string literal as follows:

    {: Grm.parserTrace("CFLOWLEVEL pointcut");
         RESULT =

However, if I put a non-integer string, I get a NumberFormatException,
and not a nice syntax error message.
Should I do something specific to use INTEGER_LITERAL?

Apart from this small detail, once again, abc has proven to be really
extensible. The only problems I had were about the access modifiers:
many classes or methods used in my extension did not belong to the
original packages, and I had to change them to be public ("protected"
did not always work, in particular in cases where it is originally used
for allowing access from classes that are in the same package, but not
subclasses.) For extensibility, it would probably be better to have
almost everything declared as "public" in abc, since the Java visibility
model is not really perfect and prevents the visibility from extensions
that would be in other packages.

I was only experimenting with abc about this cflowlevel. It works when
the counter value is equal to the value specified in the pointcut, but
there could be similar implementations using "greater than" and "less
than". I have not really investigated the problems that could arise
regarding the weaving order and the conflict with the original cflow and
cflowbelow (and there are probably some bugs left). Any comments on such
a construct?

Best regards,


Received on Sat Aug 20 11:23:10 2005

This archive was generated by hypermail 2.1.8 : Sat Aug 20 2005 - 12:10:15 BST