Array type reference not working when aspect is compiled separately from referenced type

[kriegaex]

I have found StackOverflow question #64416863 and can reproduce the author's problem with AspectJ 1.9.6. I further simplified the code a bit to now read:

public aspect MyAspect {
  after() : execution(public MaybeMissingClass MaybeMissingClass.*()) {
    System.out.println(thisJoinPoint);
  }

  after() : execution(public MaybeMissingClass[] MaybeMissingClass.*()) {
    System.out.println(thisJoinPoint);
  }
}

public class MaybeMissingClass {
  public static void main(String[] args) {
    f1();
    f2();
  }

  public static MaybeMissingClass f1() {
    System.out.println("MaybeMissingClass.f1");
    return null;
  }

  public static MaybeMissingClass[] f2() {
    System.out.println("MaybeMissingClass.f2");
    return null;
  }
}

When compiling everything together, it works as expected:

foo> ajc -cp aspectjrt.jar -1.8 MyAspect.aj MaybeMissingClass.java

foo> java -cp .;aspectjrt.jar MaybeMissingClass
MaybeMissingClass.f1
execution(MaybeMissingClass MaybeMissingClass.f1())
MaybeMissingClass.f2
execution(MaybeMissingClass[] MaybeMissingClass.f2())

When compiling the aspect separately however, the second advice unexpectedly intercepts target method f1:

foo> ajc -cp aspectjrt.jar -1.8 -outjar aspect.jar MyAspect.aj
foo\MyAspect.aj:11 [warning] no match for this type name: MaybeMissingClass [Xlint:invalidAbsoluteTypeName]
after() : execution(public MaybeMissingClass MaybeMissingClass.*()) {
                           ^^^^^^^^^^^^^^
        [Xlint:invalidAbsoluteTypeName]
foo\MyAspect.aj:11 [warning] no match for this type name: MaybeMissingClass [Xlint:invalidAbsoluteTypeName]
after() : execution(public MaybeMissingClass MaybeMissingClass.*()) {
                                             ^^^^^^^^^^^^^^^^
        [Xlint:invalidAbsoluteTypeName]
foo\MyAspect.aj:15 [warning] no match for this type name: MaybeMissingClass [Xlint:invalidAbsoluteTypeName]
after() : execution(public MaybeMissingClass[] MaybeMissingClass.*()) {
                           ^^^^^^^^^^^^^^^^
        [Xlint:invalidAbsoluteTypeName]
foo\MyAspect.aj:15 [warning] no match for this type name: MaybeMissingClass [Xlint:invalidAbsoluteTypeName]
after() : execution(public MaybeMissingClass[] MaybeMissingClass.*()) {
                                               ^^^^^^^^^^^^^^^^
        [Xlint:invalidAbsoluteTypeName]
foo\MyAspect.aj:15 [warning] advice defined in MyAspect has not been applied [Xlint:adviceDidNotMatch]

foo\MyAspect.aj:11 [warning] advice defined in MyAspect has not been applied [Xlint:adviceDidNotMatch]


6 warnings

foo> ajc -cp aspectjrt.jar -1.8 -aspectpath aspect.jar MaybeMissingClass.java

foo> java -cp .;aspect.jar;aspectjrt.jar MaybeMissingClass
MaybeMissingClass.f1
execution(MaybeMissingClass MaybeMissingClass.f1())
execution(MaybeMissingClass MaybeMissingClass.f1())
MaybeMissingClass.f2

[kriegaex]

BTW, when modifying the aspect like this experimentally

public aspect MyAspect {
  after() : execution(public MaybeMissing* MaybeMissing*.*()) {
    System.out.println(thisJoinPoint);
  }

  after() : execution(public MaybeMissing*[] MaybeMissing*.*()) {
    System.out.println(thisJoinPoint);
  }
}

now both advices match both methods, i.e. the absolute type name as such does not seem to be the (only) problem. This is true for both compiling the aspect separately or together with the target class. The program output will be:

MaybeMissingClass.f1
execution(MaybeMissingClass MaybeMissingClass.f1())
execution(MaybeMissingClass MaybeMissingClass.f1())
MaybeMissingClass.f2
execution(MaybeMissingClass[] MaybeMissingClass.f2())
execution(MaybeMissingClass[] MaybeMissingClass.f2())

There seems to be some imprecision with pointcut parsing in this case.

[kriegaex]

Some feedback from a maintainer would be welcome. Thank you.

[aclement]

Not sure what I can say, looks like a bug as you say. Maybe in parsing of point cuts (PatternParser), maybe in how array information is remembered (TypePattern hierarchy), maybe how matching of type patterns is done (TypePattern.matches*).

[kriegaex]

I started adding tests reproducing both the currently working and failing cases to the code base in a branch. For the second case with the fuzzy pointcuts - return types MaybeMissing* and MaybeMissing*[] - I noticed that matching is also wrong (too broad) when aspect and target class are compiled together, not just in the separate compilation case. I.e., there are two distinct types of bugs, even though they might be related.

[kriegaex]

For the first case with the exact type names, I compared javap -v output for the aspects generated when compiled together with the target class or separately. FWIW,

• the executable byte code looks exactly identical,
• the separately compiled aspect's embedded binary org.aspectj.weaver.Advice and org.aspectj.weaver.WeaverState data are larger than the other one's,
• the aspect compiled together with the target class contains some constant table data which the other aspect does not:

  #34 = Utf8               LMaybeMissingClass;
  ...
  #51 = Utf8               [LMaybeMissingClass;
  

  It is not a big surprise that this type information is not available in the separately compiled aspect, I am just collecting data at thios point.

[kriegaex]

Not sure what I can say, looks like a bug as you say. Maybe in parsing of point cuts (PatternParser), maybe in how array information is remembered (TypePattern hierarchy), maybe how matching of type patterns is done (TypePattern.matches*).

Pointcut parsing and array information storage seem to be OK. In both cases (exact and fuzzy/wildcard type patterns), TypePattern.dim equals 1 after parsing the pointcuts. I need to debug more, but it looks as if it might actually be a matching rather than a parsing or storage problem.

[kriegaex]

I managed to locally fix the matcher for one-dimensional array return types. For multi-dimensional ones like MaybeMissingClass[][] however, currently it only works when compiling aspect and target class together. When creating a separate aspect library, the resulting aspect somehow only contains 2 instead of 3 advice methods for this configuration:

public aspect ExactlyMatchingAspect {
  after() : execution(public MaybeMissingClass MaybeMissingClass.*()) {
    System.out.println(thisJoinPoint);
  }

  after() : execution(public MaybeMissingClass[] MaybeMissingClass.*()) {
    System.out.println(thisJoinPoint);
  }

  after() : execution(public MaybeMissingClass[][] MaybeMissingClass.*()) {
    System.out.println(thisJoinPoint);
  }
}

Maybe there is something wrong in equals and/or hashCode methods. I am documenting this for myself, because I will be very busy during the next few weeks starting tomorrow. Maybe I will not get around to continuing the debug session in a while, so I am documenting the status quo for now.

---

Update: I have a local prototype working with multi-dimensional array return types, but it needs to be verified, tidied up and checked. E.g., so far I only tried with arrays of reference types, not of primitive types yet. While I am at it, I also want to look into array type matching for method parameter and field types, not just return types.

[kriegaex]

If you look at the merged PR, this issue became considerably bigger than I thought, because along the way I also improved the syntax for array matching. So, this was not just a simple bugfix.