Evidence-Based Comparison of Modularity Support Between Java and Object Teams

Background: Aspect-oriented programming (AOP) is an emerging programming paradigm whose focus is about improving modularity, with an emphasis on the modularization of crosscutting concerns. Objective: The goal of this paper is to assess the extent to which an AOP language -ObjectTeams/Java (OT/J) -improves the modularity of a software system. This improvement has been claimed but, to the best of our knowledge, this paper is the first attempting to present quantitative evidence of it. Method: We compare functionally-equivalent implementations of the Gang-of-Four design patterns, developed in Java and OT/J, using software metrics. Results: The results of our comparison support the modularity improvement claims made in the literature. For six of the seven metrics used, the OT/J versions of the patterns obtained significantly better results. Limitations: This work uses a set of metrics originally defined for object-oriented (OO) systems. It may be the case that the metrics are biased, in that they were created in the context of OO programming (OOP), before the advent of AOP. We consider this comparison a stepping stone as, ultimately, we plan to assess the modularity improvements with paradigm independent metrics, which will conceivably eliminate the bias. Each individual example from the sample used in this paper is small. In future, we plan to replicate this experiment using larger systems, where the benefits of AOP may be more noticeable. Conclusion: This work contributes with evidence to fill gaps in the body of quantitative results supporting alleged benefits to software modularity brought by AOP languages, namely OT/J.

💡 Research Summary

The paper presents an empirical study that compares the modularity support offered by the aspect‑oriented language ObjectTeams/Java (OT/J) with that of plain Java. The authors focus on a set of well‑known Gang‑of‑Four (GoF) design patterns, implementing each pattern both in Java and in OT/J. In total, 41 pattern instances are examined (23 from the Hannemann & Kiczales repository and 18 from Cooper’s repository).

To assess modularity, the study uses seven traditional object‑oriented metrics that are available through the Eclipse OTDT plug‑in: Coupling Between Object classes (CBO), Number of Classes Used By this Class (NCUBC), Number of Classes Using this Class (NCUC), Response For a Class (RFC), Number of Children (NOC), Depth of Inheritance Tree (DIT), and Lack of Cohesion in Methods (LCOM). All metrics are computed with the “closed scope” option, meaning that only the classes, teams, and roles belonging to a particular pattern implementation are considered. For every metric except DIT, values are normalized by the total number of modules (classes, teams, roles, and implementations) in the pattern to mitigate size differences.

The independent variable is a binary flag indicating whether the implementation is written in OT/J (true) or Java (false). For each metric the authors formulate a null hypothesis (no significant difference) and an alternative hypothesis (OT/J provides a significant improvement). Statistical analysis is performed using the non‑parametric Wilcoxon signed‑rank test, appropriate for the paired nature of the data (each pattern has a Java and an OT/J version).

Results show that OT/J outperforms Java on six of the seven metrics with statistical significance (p < 0.05): CBO, NCUBC, NCUC, RFC, NOC, and LCOM. In these cases OT/J implementations exhibit lower coupling, fewer classes used or using a given class, fewer method calls, fewer immediate subclasses, and higher cohesion. The DIT metric shows no significant difference, indicating that inheritance depth is not affected by the language choice.

The authors attribute these improvements to core OT/J concepts. A “Team” unifies class and package responsibilities, while a “Role” binds to a base class and can intercept or delegate method calls through call‑in and call‑out bindings. These mechanisms enable fine‑grained separation of cross‑cutting concerns without the code scattering typical of pure OOP. Additional features such as dynamic activation/deactivation of teams and decapsulation further increase flexibility while preserving modular boundaries.

The paper also discusses limitations. The metrics employed were originally devised for OO systems and may be biased against AOP constructs; the authors acknowledge the need for paradigm‑independent metrics to obtain a truly neutral assessment. Moreover, the experimental material consists of small, self‑contained pattern examples, which may not reflect the behavior of large, real‑world code bases. Metrics like Lines of Code and total number of classes/interfaces were excluded because OT/J’s teams and roles are not counted in the same way as Java classes.

Future work is outlined: development of a set of paradigm‑independent modularity metrics, replication of the experiment on larger industrial systems, and inclusion of other AOP languages such as AspectJ for broader comparison.

In conclusion, the study provides the first quantitative evidence that ObjectTeams/Java can deliver measurable modularity benefits over traditional Java implementations, supporting claims made in the literature about the superiority of OT/J’s decoupling mechanisms. This evidence is valuable for researchers studying language design and for practitioners evaluating whether to adopt aspect‑oriented techniques in their software projects.