Engineering and Technology

Permanent URI for this collection

https://nru.uncst.go.ug/handle/123456789/818

Browse

Browsing Engineering and Technology by Subject "APIs"

Now showing 1 - 3 of 3
  • 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
    Co-evolution of the Eclipse SDK Framework and its Third-party Plug-ins
    (IEEE, 2013) Businge, John
    Today, when constructing a new software system, many developers build their systems on top of frameworks. Eclipse framework is one such popular and widely adopted framework that has been evolving for over a decade. Like many other evolving software systems, the Eclipse SDK framework has both stable and supported APIs (good interfaces) and unstable, discouraged and unsupported non-APIs (bad interfaces). However, despite being discouraged by Eclipse, in our experience, the usage of bad interfaces is not uncommon. In this thesis, by means of a series of empirical studies, we quantify/qualify some the challenges faced by Eclipse thirdparty plug-in developers in using the interfaces provided by the Eclipse SDK framework. Furthermore, we propose solutions to the identified challenges, like changes in development strategy to both interface providers and interface users. In particular, the lessons learned from this study can provide valuable information in particular to the interface providers, i.e., Eclipse SDK developers, and the interface uses, i.e., ETP developers, in co-evolving the Eclipse framework. In general, the lessons learned can be transferable to other framework ecosystem.
  • 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.