Maintaining the consistency of class libraries during their evolution

MeziniMira,

doi:10.1145/263700.263701

Cited by 6 publications

(3 citation statements)

References 18 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The two effects also interact, in that adding a method to a module early in the chain can lead to a spurious match later on, with unintended effects. The situation is similar to that of accidental inheritance [10] or accidental method capture [11].…”

Section: Discussionmentioning

confidence: 97%

Aspectual Collaborations: Combining Modules and Aspects

Lieberherr¹

2003

The Computer Journal

View full text Add to dashboard Cite

Complex behavior often resists clean modularization in object-oriented languages. Aspectoriented programming tackles this problem by providing ¤exible module boundaries that can span and partition classes. However, in order to achieve this ¤exibility, valuable modularity mechanisms, such as encapsulation and external composition, are lost. The ability to separately compile or reason about a modular unit is also compromised. We propose that this tradeoff is not necessary, and that by expressing aspects as part of our modules, we can restore lost modular properties while maintaining aspectual features. As a concrete demonstration, we present the main features of Aspectual Collaborations, and show how these interact to combine modularity with aspectual behavior. The expressiveness of Aspectual Collaborations, AspectJ, and Hyper/J are compared using a challenge problem, allowing us to estimate the effectiveness of the approach.

show abstract

Section: Discussionmentioning

confidence: 97%

Aspectual Collaborations: Combining Modules and Aspects

Lieberherr¹

2003

The Computer Journal

View full text Add to dashboard Cite

show abstract

“…Related works [10] focused on support for clients migrating to a newer library version. Likewise, other works [39,54,55,56] studied how library maintainers balance API compatibility with an evolving library.…”

Section: Threats To Validitymentioning

confidence: 99%

An empirical study on the impact of refactoring activities on evolving client-used APIs

Kula

Ouni

Germán

et al. 2018

Information and Software Technology

View full text Add to dashboard Cite

Context: Refactoring is recognized as an effective practice to maintain evolving software systems. For software libraries, we study how library developers refactor their Application Programming Interfaces (APIs), especially when it impacts client users by breaking an API of the library. Objective: Our work aims to understand how clients that use a library API are affected by refactoring activities. We target popular libraries that potentially impact more library client users. Method: We distinguish between library APIs based on their client-usage (refereed to as client-used APIs) in order to understand the extent to which API breakages relate to refactorings. Our tool-based approach allows for a large-scale study across eight libraries (i.e., totaling 183 consecutive versions) with around 900 clients projects. Results: We find that library maintainers are less likely to break client-used API classes. Quantitatively, we find that refactoring activities break less than 37% of all client-used APIs. In a more qualitative analysis, we show two documented cases of where non-refactoring API breaking changes are motivated by other maintenance issues (i.e., bug fix and new features) and involve more complex refactoring operations. Conclusion: Using our automated approach, we find that library developers are less likely to break APIs and tend to break client-used APIs when addressing these maintenance issues.

show abstract

“…Mezini proposes a metalevel cooperation contract that allows library designers to declare properties of classes that are propagated to subclasses [26]. These properties are specified in a cooperation contract language (CCL).…”

Section: Related Workmentioning

confidence: 99%

Safely creating correct subclasses without seeing superclass code

Ruby

Leavens

2000

SIGPLAN Not.

View full text Add to dashboard Cite

A major problem for object-oriented frameworks and class libraries is how to provide enough information about a superclass, so programmers can safely create new subclasses without giving away the superclass's code. Code inherited from the superclass can call down to methods of the subclass, which may cause nontermination or unexpected behavior. We describe a reasoning technique that allows programmers, who have no access to the code of the superclass, to determine both how to safely override the superclass's methods and when it is safe to call them. The technique consists of a set of rules and some new forms of specification. Part of the specification would be generated automatically by a tool, a prototype of which is planned for the formal specification language JML. We give an example to show the kinds of problems caused by method overrides and how our technique can be used to avoid them. We also argue why the technique is sound and give guidelines for library providers and programmers that greatly simplify reasoning about how to avoid problems caused by method overrides.

show abstract

Maintaining the consistency of class libraries during their evolution

Cited by 6 publications

References 18 publications

Aspectual Collaborations: Combining Modules and Aspects

Aspectual Collaborations: Combining Modules and Aspects

An empirical study on the impact of refactoring activities on evolving client-used APIs

Safely creating correct subclasses without seeing superclass code

Contact Info

Product

Resources

About