An (abstract?) base aspect in annotation-based @AspectJ syntax, containing an if() pointcut like this:
@Pointcut("if()")
public static boolean isEnabled() {
return true;
}
An aspect extending the base aspect
A compiler step 1 compiling the base aspect separately.
A compiler step 2 compiling the extending aspect + an optional demo application.
This will yield an AJC error as follows (line breaks added for better readability):
com\example\AbstractAspectWithStatic.aj [error]
can't override pointcut com.example.AbstractAspectWithStatic.isEnabled()
with pointcut com.example.AbstractAspectWithStatic.isEnabled()
return types don't match
Noteworthy:
Interestingly, when running the demo application after the failed compilation step 2, the aspect (at least my simple example one) seems to be applied and to work normally.
The same scenario with a native base aspect works as expected without any compiler or runtime errors. Whether the extending aspect is in native or annotation syntax, does not seem to be so important.
In both the native and annotation syntax scenarios, when compiling both aspects together without any binary weaving step, there are no problems.
How to reproduce
Example code
We need at least those two classes:
package com.example;
import org.aspectj.lang.ProceedingJoinPoint;
import org.aspectj.lang.annotation.Around;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
@Aspect
public abstract class AbstractAspectWithStatic {
@Pointcut("if()")
public static boolean isEnabled() {
return true;
}
@Pointcut
public abstract void pointCut();
@Around("isEnabled() && pointCut()")
public Object myAdvice(ProceedingJoinPoint joinPoint) throws Throwable {
System.out.println("AbstractAspectWithStatic: " + joinPoint);
return joinPoint.proceed();
}
}
package com.example;
import org.aspectj.lang.annotation.Aspect;
import org.aspectj.lang.annotation.Pointcut;
@Aspect
public class InheritingAspect extends AbstractAspectWithStatic {
@Pointcut("execution(* com.example.Application.*(..))")
public void pointCut() {}
}
If we want to run the compiled code, we also need this demo application:
package com.example;
public class Application {
public static void main(String[] args) {
System.out.println("Hello, World!");
doSomething();
}
public static void doSomething() {
System.out.println("Doing something...");
}
}
For a negative or regression test, here are two native syntax aspects:
Preface
Originally reported as https://github.com/mojohaus/aspectj-maven-plugin/issues/222, the issue is unrelated to AspectJ Maven Plugin. Therefore, I am creating an issue here on behalf of @stendler.
The issue needs the following to reproduce:
An (abstract?) base aspect in annotation-based @AspectJ syntax, containing an
if()
pointcut like this:An aspect extending the base aspect
A compiler step 1 compiling the base aspect separately.
A compiler step 2 compiling the extending aspect + an optional demo application.
This will yield an AJC error as follows (line breaks added for better readability):
Noteworthy:
Interestingly, when running the demo application after the failed compilation step 2, the aspect (at least my simple example one) seems to be applied and to work normally.
The same scenario with a native base aspect works as expected without any compiler or runtime errors. Whether the extending aspect is in native or annotation syntax, does not seem to be so important.
In both the native and annotation syntax scenarios, when compiling both aspects together without any binary weaving step, there are no problems.
How to reproduce
Example code
We need at least those two classes:
If we want to run the compiled code, we also need this demo application:
For a negative or regression test, here are two native syntax aspects:
Compiling and running the application
Reproducing the compiler error
Here, we see the compiler error in step 2 and the application running fine despite that error.
Negative/regression test
No problems with native syntax aspects.
Single-stage compilation
If everything is compiled together, it works as expected.
AspectJ Maven reproducer
Using this POM and a standard Maven directory layout, the problem can also be reproduced easily:
Console log: