How Stable Are Eclipse Application Framework Internal Interfaces?

Abstract

Eclipse framework provides two interfaces: stable interfaces (APIs) and unstable interfaces (non-APIs). Despite the non-APIs being discouraged and unsupported, their usage is not uncommon. Previous studies showed that applications using relatively old non-APIs are more likely to be compatible with new releases compared to the ones that used newly introduced non-APIs; that the growth rate of non-APIs is nearly twice as much as that of APIs; and that the promotion of non-API to APIs happens at a slow pace since API providers have no assistance to identify public interface candidates. Motivated by these findings, our main aim was to empirically investigate the entire population (2,380K) of non-APIs to find the non-APIs that remain stable for a long period of time. We employ cross-project clone detection to identify whether non-APIs introduced in a given Eclipse release remain stable over successive releases. We provide a dataset of 327K stable non-API methods that can be used by both Eclipse interface providers as possible candidates of promotion. Instead of promoting non-APIs which are too fine-grained, we summarized the non-API methods groups in given classes that are stable together and present class-level non-APIs that possible candidates promotion. We have shown that it is possible to predict the stability of a non-API in subsequent Eclipse releases with a precision of ≥ 56%, a recall of ≥ 96% and an AUC of ≥ 92% and an Fmeasure of ≥ 81%. We have also shown that the metrics of length of a method and number of method parameters in a non-API method are very good predictors for the stability of the non-API in successive Eclipse releases. The results provided can help the API providers to estimate a priori how much work could be involved in performing the promotion.

An Empirical Study of Bugs in Eclipse Stable Internal Interfaces

“…This study is an extension of our recent work where we studied the stability of internal interfaces [17] during the evolution of the Eclipse framework. In this study, we analyzed stable internal interfaces for possible bugs.…”

“…can contain bugs, there exist a need to investigate the stable non-API for possible bugs before they can be considered for promotion. Using SonarQube software quality tool [18], this study discovered that there exist bugfree stable non-APIs among the stable non-API discovered in our previous study [17]. In addition to their stability and being bug-free these stable non-APIs can be good candidates for promotion to stable APIs and should be recommended to application developers.…”

“…In our recent study [17], using clone detection techniques we investigated the stability of Eclipse internal interfaces over subsequent Eclipse releases. In the same study, we provided a dataset of 327K old stable non-API methods that can be used by framework developer as possible candidates for promotion.…”

“…We understand that Eclipse providers normally perform non-API promotion at the level of a class. Promotion at the method level seems to be fine grained thus from our previous study [17], we summarized the stable non-API methods that are possible candidates for promotion to APIs to the class-level. For example, instead of promoting a single non-API method, the providers can promote groups of non-API methods that are stable together in a single class.…”

BreakBot: Analyzing the Impact of Breaking Changes to Assist Library Evolution

“…To enact stability, libraries tend to assume that BCs are always harmful [13]. This reasoning has led to the misconception that stability is equivalent to change stagnation [2,4,18]. However, we claim that stability is the capability to not break clients even under the presence of change.…”