AspectJ @DeclareMixin, Methods that are not declared by an interface are not weaved

Question

I am trying to give a default implementation to Methods declared by java.lang#Object. Here is an MCVE for the problem I encounter. In the interface IAspect I declare an equals Method. In the implementation of this class I define it as always false. So in theory the main method of the example should output false but it outputs true. When decompiling the class said method is not there. I know that the project setup works since for the other Method in the interface AspectJ correctly generates the needed code. Is it even possible to do this with Annotations? I usually wrote my AspectJ code with the AspectJ-Syntax. Which worked as intended with no flaws. But I am not sure if I am able to extract the AspectJ code in a seperate library like in my MCVE if I use the AspectJ-Syntax.

So my actual questions:

• Is it possible to give default implementations to non abstract Methods that are inherited from other Classes and not an interface that defines the Aspects?
• Is it possible to use AspectJ-Syntax in a library and add this library as AspecJ-Dependency so that my code still uses the externally defined aspects?

Depending on the answers I will decide how to further progress.

Answer 1

Just like in my answer to your previous question, again I created a pull request #2 for you. What it does:

• Convert your annotation-style aspect into a native syntax one, declaring the interface and its method implementations inline, getting rid of three of your previous classes. This is more elegant and readable IMO. I do not like annotation-style syntax anyway, and as you found out already, the latter has limitations which native syntax does not have.

• Re-structure your two separate Maven modules into a root/parent POM used to configure commonly used dependencies and plugins which are then only referenced and amended with other configuration details where necessary in the two child POMs. The library POM now has AspectJ Maven plugin in it again because we need the AJ compiler also for the aspect library due to the native syntax. Of course you can use native syntax aspects in a library and this module shows you how.

• Another benefit is that now you can just call mvn clean package on the parent POM and the library will automatically be built and packaged before it is used by the application module. No more ugly need to use mvn clean install on the library first. Actually, install is not needed at all in order to build your application.

Now if after mvn clean package you run the application from the root directory, you will see the following:

$ java -jar example/target/example-1.0.0-SNAPSHOT.one-jar.jar
Test
false
false
hello

This is what you want, isn't it?