Resolving the Joinpoint hierarchy problem

[lm-sousa]

On the Java side, the WeaverGenerator + LanguageSpecification projects handle the generation of the Joinpoint abstracts. These abstracts form the foundation of the joinpoint model but suffer from a serious issue due to the hierarchy they are placed in.

When we have a series of joinpoints, let's say:

A1 — C1
 |
A2 — C2
 |
A3 — C3

where Ax are the joinpoint abstract and Cx their concrete counterparts.

If C1 overrides a method, I create an object of type C3 and call that same method, the version of the method that gets executed is the base-class', not C1's version.

Furthermore, what is currently done is that in C3's constructor a new object of type C2 is created and in C2's constructor a new object of C1 is created. This goes all the way up the hierarchy so when a joinpoint type is instantiated that is N degrees removed from the base/primordial joinpoint type actually results in N objects being created. This constructor recursivity is also done by hand and depends on the developer's memory of the pattern. This is not acceptable and needs a fundamental change.

[joaobispo]

This issue in the past introduced buggy behaviour, which has been solved for some time now (the solution was for all abstract join points to override all inherited methods).

However, it is far from ideal an needs to be solved. One solution is for the Weaver Generator to also generate the concrete classes, when they do not exist (e.g., by adding a -c flag with the destination package as argument). By generating concrete classes, it is possible to then have the following hierarchy:

A1
 |
C1
 |
A2
 |
C2
 |
A3
 |
C3

A proof-of-concept on how this could work can be seen in a PR of the Clava repository.