Skip to content

Resolving the Joinpoint hierarchy problem #95

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Type

    Fields

    No fields configured for Task.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions