Abstract
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 third-party 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.
Similar content being viewed by others
Notes
In the rest of the paper, the word SDK refers to Eclipse SDK.
In this paper the use the term interfaces to refer to Java classes and interfaces.
In this paper we will use the following words interchangeably: API and a good interface; non-API and a bad interface.
We stress that the median of the difference is not the same as the difference in medians.
One of the ETPs, ShellEd, had one unused non-API import in its early versions. This ETP now belongs Classification II ETPs. Five of the remaining ETPs are analyzed below.
The ETP gted had an unused non-API in one of the intermediate versions. This ETP should be categorized as a good ETP.
References
Bolour, A. (2003). Notes on the Eclipse plug-in architecture (2003). http://www.eclipse.org/articles/Article-Plug-in-architecture/plugin_architecture.html. Accessed 01 Jan 2012.
Bosch, J., Molin, P., Mattsson, M., & Bengtsson, P. (2000). Object-oriented framework-based software development: problems and experiences. ACM Computing Surveys 32.
Brugali, D., Broten, G., Cisternino, A., Colombo, D., Fritsch, J., Gerkey, B., Kraetzschmar, G., Vaughan, R., & Utz, H. (2007) Trends in robotic software frameworks. In: Brugali, D. (Ed.), Software engineering for experimental robotics. Tracts in Advanced Robotics, vol. 30. Springer, pp. 259–266.
Businge, J. (2013a). Co-evolution of the Eclipse framework and its third-party plug-ins. Ph.D. thesis, Eindhoven University of Technology, Eindhoven, The Netherlands.
Businge, J. (2013b). Co-evolution of the Eclipse SDK framework and its third-party plug-ins. In: CSMR, pp. 427–430.
Businge, J. (2013c). Eclipse third-party plug-ins source code. doi:10.4121/uuid:ce5e73ba-4087-4a7a-afb1-e442b4b6c0ec.
Businge, J., Serebrenik, A., & van den Brand, M. G. J. (2010). An empirical study of the evolution of Eclipse third-party plug-ins. In: EVOL-IWPSE’10, pp. 63–72.
Businge, J., Serebrenik, A., & van den Brand, M. G. J. (2012a). Compatibility prediction of Eclipse third-party plug-ins in new Eclipse releases. In: SCAM, pp. 164–173.
Businge, J., Serebrenik, A., & van den Brand, M. G. J. (2012b) Eclipse API usage: the good and the bad. In: SQM, pp. 54–62.
Businge, J., Serebrenik, A., & van den Brand, M. G. J. (2012c). Survival of Eclipse third-party plug-ins. In: ICSM, pp. 368–377.
Businge, J., Serebrenik, A., & van den Brand, M. G. J. (2013) Analyzing the Eclipse API usage: Putting the developer in the loop. In: CSMR, pp. 37–46.
Dagenais, B., & Robillard, M. P. (2011). Recommending adaptive changes for framework evolution. ACM Trans. Softw. Eng. Methodol. 20:19:1–19:35.
Dig, D., & Johnson, R. (2009). How do APIs evolve? A story of refactoring. J. Softw. Maint. Evol. 18, 83–107.
Grechanik, M., McMillan, C., DeFerrari, L., Comi, M., Crespi, S., Poshyvanyk, D., Fu, C., Xie, Q., & Ghezzi, C. (2010). An empirical investigation into a large-scale Java open source code repository. In: ESEM’10, pp. 11:1–11:10.
Hodges, J. L., & Lehmann, E. L. (1963). Estimates of location based on rank tests. The Annals of Mathematical Statistics 34(2), 598–611.
Holmes, R., & Walker, R.J. (2007). Informing Eclipse API production and consumption. In: OOPSLA’07, pp. 70–74.
Konstantopoulos, D., Marien, J., Pinkerton, M., & Braude, E. (2009). Best principles in the design of shared software. In: COMPSAC’09, pp. 287–292.
Lämmel, R., Pek, E., & Starek, J. (2011) Large-scale, AST-based API-usage analysis of open-source Java projects. In: SAC’11, pp. 1317–1324.
Lehman, M. M., & Belady, L. A. (1985). Program evolution: processes of software change. Academic Press, London.
Mileva, Y. M., Dallmeier, V., & Zeller, A. (2010). Mining API popularity. In: TAIC PART’10, pp. 173–180.
Moser, S., & Nierstrasz, O. (1996). The effect of object-oriented frameworks on developer productivity. Computer 29(9): 45–51.
Nguyen, H. A., Nguyen, T. T., Wilson Jr., G., Nguyen, A. T., Kim, M., & Nguyen, T. N. (2010). A graph-based approach to API usage adaptation. In: OOPSLA, pp. 302–321.
Norušis, M.J. (2008). SPSS 16.0 guide to data analysis. Prentice Hall Inc., Upper Saddle River, NJ.
Poncin, W., Serebrenik, A., & van den Brand, M. G. J. (2011). Process mining software repositories. In: CSMR, pp. 5–14.
Rainer, A., & Gale, S. (2005). Evaluating the quality and quantity of data on open source software projects. In: ICOSS, pp. 11–15.
des Rivières, J. (2001) How to use the Eclipse API. http://www.eclipse.org/articles/article.php?file=Article-API-Use/index.html. Accessed 01 Jan 2012.
des Rivières, J. (2007). Evolving Java-based APIs (2007). http://wiki.eclipse.org/Evolving_Java-based_APIs. Accessed 01 Jan 2012.
Rosenkranz, G. K. (2010). A note on the Hodges-Lehmann estimator. Pharmaceutical statistics 9(2), 162–167.
Schröter, A., Zimmermann, T., & Zeller, A. (2006). Predicting component failures at design time. In: ISESE’06, pp. 18–27.
Serebrenik, A., & van den Brand, M. G. J. (2010) Theil index for aggregation of software metrics values. In: ICSM’10, pp. 1–9.
Tourwe, T., & Mens, T. (2003). Automated support for framework-based software. In: ICSM’03, pp. 148–157.
Vasilescu, B., Serebrenik, A., & van den Brand, M. G. J. (2010). Comparative study of software metrics’ aggregation techniques. In: BENEVOL, pp. 1–5.
Vasilescu, B., Serebrenik, A., & van den Brand, M. G. J. (2011). You can’t control the unfamiliar: A study on the relations between aggregation techniques for software metrics. In: ICSM’11, pp. 313–322.
Wu, W., Guéhéneuc, Y. G., Antoniol, G., & Kim, M. (2010). AURA: A hybrid approach to identify framework evolution. In: ICSE, pp. 325–334.
Xing, Z., & Stroulia, E. (2006). Refactoring practice: How it is and how it should be supported: an Eclipse case study. In: ICSM’06, pp. 458–468.
Author information
Authors and Affiliations
Corresponding author
Rights and permissions
About this article
Cite this article
Businge, J., Serebrenik, A. & van den Brand, M.G.J. Eclipse API usage: the good and the bad. Software Qual J 23, 107–141 (2015). https://doi.org/10.1007/s11219-013-9221-3
Published:
Issue Date:
DOI: https://doi.org/10.1007/s11219-013-9221-3