Software Quality Journal

, Volume 23, Issue 1, pp 107–141 | Cite as

Eclipse API usage: the good and the bad

  • John Businge
  • Alexander Serebrenik
  • Mark G. J. van den Brand


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.


Eclipse API usage Software evolution 


  1. Bolour, A. (2003). Notes on the Eclipse plug-in architecture (2003). Accessed 01 Jan 2012.
  2. Bosch, J., Molin, P., Mattsson, M., & Bengtsson, P. (2000). Object-oriented framework-based software development: problems and experiences. ACM Computing Surveys 32.Google Scholar
  3. 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.Google Scholar
  4. 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.Google Scholar
  5. Businge, J. (2013b). Co-evolution of the Eclipse SDK framework and its third-party plug-ins. In: CSMR, pp. 427–430.Google Scholar
  6. Businge, J. (2013c). Eclipse third-party plug-ins source code. doi: 10.4121/uuid:ce5e73ba-4087-4a7a-afb1-e442b4b6c0ec.
  7. 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.Google Scholar
  8. 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.Google Scholar
  9. Businge, J., Serebrenik, A., & van den Brand, M. G. J. (2012b) Eclipse API usage: the good and the bad. In: SQM, pp. 54–62.Google Scholar
  10. Businge, J., Serebrenik, A., & van den Brand, M. G. J. (2012c). Survival of Eclipse third-party plug-ins. In: ICSM, pp. 368–377.Google Scholar
  11. 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.Google Scholar
  12. Dagenais, B., & Robillard, M. P. (2011). Recommending adaptive changes for framework evolution. ACM Trans. Softw. Eng. Methodol. 20:19:1–19:35.Google Scholar
  13. Dig, D., & Johnson, R. (2009). How do APIs evolve? A story of refactoring. J. Softw. Maint. Evol. 18, 83–107.CrossRefGoogle Scholar
  14. 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.Google Scholar
  15. Hodges, J. L., & Lehmann, E. L. (1963). Estimates of location based on rank tests. The Annals of Mathematical Statistics 34(2), 598–611.CrossRefzbMATHMathSciNetGoogle Scholar
  16. Holmes, R., & Walker, R.J. (2007). Informing Eclipse API production and consumption. In: OOPSLA’07, pp. 70–74.Google Scholar
  17. Konstantopoulos, D., Marien, J., Pinkerton, M., & Braude, E. (2009). Best principles in the design of shared software. In: COMPSAC’09, pp. 287–292.Google Scholar
  18. 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.Google Scholar
  19. Lehman, M. M., & Belady, L. A. (1985). Program evolution: processes of software change. Academic Press, London.Google Scholar
  20. Mileva, Y. M., Dallmeier, V., & Zeller, A. (2010). Mining API popularity. In: TAIC PART’10, pp. 173–180.Google Scholar
  21. Moser, S., & Nierstrasz, O. (1996). The effect of object-oriented frameworks on developer productivity. Computer 29(9): 45–51.CrossRefGoogle Scholar
  22. 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.Google Scholar
  23. Norušis, M.J. (2008). SPSS 16.0 guide to data analysis. Prentice Hall Inc., Upper Saddle River, NJ.Google Scholar
  24. Poncin, W., Serebrenik, A., & van den Brand, M. G. J. (2011). Process mining software repositories. In: CSMR, pp. 5–14.Google Scholar
  25. Rainer, A., & Gale, S. (2005). Evaluating the quality and quantity of data on open source software projects. In: ICOSS, pp. 11–15.Google Scholar
  26. des Rivières, J. (2001) How to use the Eclipse API. Accessed 01 Jan 2012.
  27. des Rivières, J. (2007). Evolving Java-based APIs (2007). Accessed 01 Jan 2012.
  28. Rosenkranz, G. K. (2010). A note on the Hodges-Lehmann estimator. Pharmaceutical statistics 9(2), 162–167.MathSciNetGoogle Scholar
  29. Schröter, A., Zimmermann, T., & Zeller, A. (2006). Predicting component failures at design time. In: ISESE’06, pp. 18–27.Google Scholar
  30. Serebrenik, A., & van den Brand, M. G. J. (2010) Theil index for aggregation of software metrics values. In: ICSM’10, pp. 1–9.Google Scholar
  31. Tourwe, T., & Mens, T. (2003). Automated support for framework-based software. In: ICSM’03, pp. 148–157.Google Scholar
  32. Vasilescu, B., Serebrenik, A., & van den Brand, M. G. J. (2010). Comparative study of software metrics’ aggregation techniques. In: BENEVOL, pp. 1–5.Google Scholar
  33. 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.Google Scholar
  34. 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.Google Scholar
  35. 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.Google Scholar

Copyright information

© Springer Science+Business Media New York 2013

Authors and Affiliations

  • John Businge
    • 1
  • Alexander Serebrenik
    • 1
  • Mark G. J. van den Brand
    • 1
  1. 1.Eindhoven University of TechnologyEindhovenThe Netherlands

Personalised recommendations