Browsing by Author "Serebrenik, Alexander"

Now showing 1 - 6 of 6
  • Thumbnail Image
    Item
    Analyzing the Eclipse API Usage: Putting the Developer in the Loop
    (IEEE, 2013) Businge, John; Serebrenik, Alexander; van den Brand, Mark
    Eclipse guidelines distinguish between two types of interfaces provided to third-party developers, i.e., APIs and non-APIs. APIs are stable and supported, while non-APIs are unstable, unsupported and discouraged as they are subject to arbitrary change or removal without notice. In our previous work, we found that despite the discouragement of Eclipse, the use of non-APIs in Eclipse third-party plug-ins (ETPs) is not uncommon. Furthermore, we found that these non-APIs are the main cause of ETP incompatibilities in forthcoming releases of the Eclipse. In the current work we conducted a survey aiming at understanding why do the ETP developers use non-APIs. We have observed that developers with a level of education of up to master degree have a tendency not to read product manuals/ guidelines. Furthermore, while for less experienced developers instability of the non-APIs overshadows their benefits, more experienced developers prefer to enjoy the benefits of non-APIs despite the instability problem. Finally, we have observed that there are no significant differences between Open Source and commercial Eclipse products in terms of awareness of Eclipse guidelines and interfaces, Eclipse product size and updating of Eclipse product in the new SDK releases.
  • Thumbnail Image
    Item
    Compatibility Prediction of Eclipse Third-Party Plug-ins in New Eclipse Releases
    (IEEE, 2012) Businge, John; Serebrenik, Alexander; van den Brand, Mark
    Incompatibility between applications developed on top of frameworks with new versions of the frameworks is a big nightmare to both developers and users of the applications. Understanding the factors that cause incompatibilities is a step to solving them. One such direction is to analyze and identify parts of the reusable code of the framework that are prone to change. In this study we carried out an empirical investigation on 11 Eclipse SDK releases (1.0 to 3.7) and 288 Eclipse thirdparty plug-ins (ETPs) with two main goals: First, to determine the relationship between the age of Eclipse non-APIs (internal implementations) used by an ETP and the compatibility of the ETP. We found that third-party plug-in that use only old non-APIs have a high chance of compatibility success in new SDK releases compared to those that use at least one newly introduced non-API. Second, our goal was to build and test a predictive model for the compatibility of an ETP, supported in a given SDK release in a newer SDK release. Our findings produced 23 statistically significant prediction models having high values of the strength of the relationship between the predictors and the prediction (logistic regression R2 of up to 0.810). In addition, the results from model testing indicate high values of up to 100% of precision and recall and up to 98% of accuracy of the predictions. Finally, despite the fact that SDK releases with API breaking changes, i.e., 1.0, 2.0 and 3.0, have got nothing to do with non-APIs, our findings reveal that non-APIs introduced in these releases have a significant impact on the compatibility of the ETPs that use them.
  • Thumbnail Image
    Item
    Eclipse API usage: the good and the bad
    (Software Quality Journal, 2015) Businge, John; Serebrenik, Alexander; van den Brand, Mark G. J.
    Today, when constructing software systems, many developers build their systems on top of frameworks. Eclipse is such a framework that has been in existence for over a decade. Like many other evolving software systems, the Eclipse platform has both stable and supported interfaces (‘‘good’’) and unstable, discouraged and unsupported interfaces (‘‘bad’’). In this study, we investigate Eclipse interface usage by Eclipse thirdparty plug-ins (ETPs) based on whether they use bad interfaces or not. The investigations, based on empirical analysis present the following observations. First, we discovered that 44 % of the 512 analyzed Eclipse third-party plug-ins depend on ‘‘bad’’ interfaces and that developers continue to use ‘‘bad’’ interfaces. Second, we have observed that plug-ins that use or extend at least one ‘‘bad’’ interface are comparatively larger and use more functionality from Eclipse than those that use only ‘‘good’’ interfaces. Third, the findings show that the ETPs use a diverse set of ‘‘bad’’ interfaces. Fourth, we observed that the reason why the bad interfaces are being eliminated from the ETPs’ source code is, because (ETP developers believe) these non-APIs will cause incompatibilities when a version of the ETP is ported to new Eclipse SDK release. Finally, we observed that when developers eliminate problematic ‘‘bad’’ interfaces, they either re-implement the same functionality in their own API, find equivalent SDK good interfaces, or completely delete the entities in the ETPs’ source code that use the functionality from the ‘‘bad’’ interfaces.
  • Thumbnail Image
    Item
    An Empirical Study of the Evolution of Eclipse Third-party Plug-ins
    (International Workshop on Principles of Software Evolution (IWPSE), 2010) Businge, John; Serebrenik, Alexander; van den Brand, Mark
    Since the inception of Lehman's software evolution laws in the early 1970s, they have attracted signi cant attention from the research community. However, to our knowledge, no study of applicability of these laws on the software sys- tems that exhibit constrained evolution process has been carried out so far. In this paper we take a rst step in this direction and investigate the constrained evolution of 21 Eclipse third{party plug-ins. We investigate the trends followed by the plug-ins dependencies on Eclipse over time. The study spans 6 years of the evolution of Eclipse evolving from release 3.0 to release 3.5. Our ndings con rm the laws of continuing change, self regulation and continuing growth when metrics related to dependencies between the plug-ins and the Eclipse Architecture are considered. Unlike this, the conservation of familiarity law was not con rmed and the results for the declining quality law were inconclusive.
  • Thumbnail Image
    Item
    How Stable are Eclipse Application Framework Internal Interfaces?
    (IEEE, 2019) Businge, John; Kawuma, Simon; Openja, Moses; Bainomugisha, Engineer; Serebrenik, Alexander
    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.
  • Thumbnail Image
    Item
    Survival of Eclipse Third-party Plug-ins
    (IEEE, 2012) Businge, John; Serebrenik, Alexander; van den Brand, Mark
    Today numerous software systems are being developed on top of frameworks. In this study, we analyzed the survival of 467 Eclipse third-party plug-ins altogether having 1,447 versions. We classify these plug-ins into two categories: those that depend on only stable and supported Eclipse APIs and those that depend on at least one of the potentially unstable, discouraged and unsupported Eclipse non-APIs. Comparing the two categories of plug-ins, we observed that the plug-ins depending solely on APIs have a very high source compatibility success rate compared to those that depend on at least one of the non-APIs. However, we have also observed that recently released plug-ins that depend on non-APIs also have a very high forward source compatibility success rate. This high source compatibility success rate is due to the dependency structure of these plug-ins: recently released plug-ins that depend on non-A PIs predominantly depend on old Eclipse nonAPIs rather than on newly introduced ones. Finally, we showed that the majority of plug-ins hosted on SourceForge do not evolve beyond the first year of release.