Empirical Software Engineering

, Volume 21, Issue 3, pp 1371–1396 | Cite as

What Java developers know about compatibility, and why this matters

  • Jens DietrichEmail author
  • Kamil Jezek
  • Premek Brada


Real-world programs are neither monolithic nor static—they are constructed using platform and third party libraries, and both programs and libraries continuously evolve in response to change pressure. In case of the Java language, rules defined in the Java Language and Java Virtual Machine Specifications define when library evolution is safe. These rules distinguish between three types of compatibility—binary, source and behavioural. We claim that some of these rules are counter intuitive and not well-understood by many developers. We present the results of a survey where we quizzed developers about their understanding of the various types of compatibility. 414 developers responded to our survey. We find that while most programmers are familiar with the rules of source compatibility, they generally lack knowledge about the rules of binary and behavioural compatibility. This can be problematic when organisations switch from integration builds to technologies that require dynamic linking, such as OSGi. We have assessed the gravity of the problem by studying how often linkage-related problems are referenced in issue tracking systems, and find that they are common.


Java Binary compatibility API compatibility Empirical study User survey Linking 



We are grateful to all developers who completed the survey. We are particularly grateful to Jeff Friesen and Athen O’Shea from Java World, and Kon Soulianidis from the Melbourne Java user group. Without them, we would not have reached the critical number of responses. We would like to thank Alex Buckley and Hussain Al-Mutawa for their feedback on the puzzlers we used as questions in the survey.

The work was partially supported by European Regional Development Fund (ERDF), project “NTIS—New Technologies for the Information Society”, European Centre of Excellence, CZ.1.05/1.1.00/02.0090.

The project was evaluated by Massey University’s Human Ethics committee and approved under the Low Risk category on 5 Nov 2013.


  1. Balaban I, Tip F, Fuhrer R (2005) Refactoring support for class library migration. In: Proceedings OOPSLA ’05, OOPSLA ’05. ACM, New York, pp 265–279Google Scholar
  2. Barr M, Eisenbach S (2003) Safe upgrading without restarting. In: Proceedings ICSM’03, pp 129–137Google Scholar
  3. Bauml J, Brada P (2009a) Automated versioning in OSGi: a mechanism for component software consistency guarantee. In: Proceedings 35th EUROMICRO’09. IEEE Computer Society, pp 428–435Google Scholar
  4. Bauml J, Brada P (2009b) Automated Versioning in OSGi: a mechanism for component software consistency guarantee. In: Proceedings SEAA ’09, pp 428–435Google Scholar
  5. Belguidoum M, Dagnat F (2008) Formalization of component substitutability. Electron Notes Theor Comput Sci 215:75–92CrossRefGoogle Scholar
  6. Beugnard A, Jezequel J, Plouzeau N, Watkins D (1999) Making components contract aware. Computer 32(7):38–45CrossRefGoogle Scholar
  7. Blewitt A (2013) Jigsaw, second cut. Accessed 27 March 2014
  8. Bloch J, Gafter N (2005) Java puzzlers: traps, pitfalls, and corner cases. Addison-Wesley ProfessionalGoogle Scholar
  9. BND Tools (2014) Accessed 27 March 2014
  10. Buckley A (2007) Different kinds of compatibility. Accessed 27 March 2014
  11. Cardelli L (1991) Typeful programming. Springer, BerlinGoogle Scholar
  12. Chow K, Notkin D (1996) Semi-automatic update of applications in response to library changes. In: Proceedings ICSM’96. IEEE Computer Society, p 359Google Scholar
  13. Corwin J, Bacon DF, Grove D, Murthy Cs (2003) Mj: a rational module system for java and its applications. SIGPLAN Not 38(11):241–254CrossRefGoogle Scholar
  14. Cossette BE, Walker RJ (2012) Seeking the ground truth: a retroactive study on the evolution and migration of software libraries. In: Proceedings FSE’12. ACM, p 55Google Scholar
  15. Darcy JD (2008) Kinds of compatibility: source, binary, and behavioral. Accessed 27 March 2014
  16. Darcy JD (2009) JDK release types and compatibility regions. Accessed 27 March 2014
  17. des Rivières J (2007) Evolving Java-based APIs. Accessed 27 March 2014
  18. Dietrich J, Jezek K, Brada P (2014a) Broken promises—an empirical study into evolution problems in java programs caused by library upgrades. In: Proceedings CSRMR’14. IEEEGoogle Scholar
  19. Dietrich J, Jezek K, Brada P (2014b) Broken promises: an empirical study into evolution problems in java programs caused by library upgrades. In: 2014 Software evolution Week-IEEE conference on software maintenance, reengineering and reverse engineering (CSMR-WCRE). IEEE, pp 64–73Google Scholar
  20. Dig D, Johnson R (2006) How do APIs evolve? A story of refactoring. J Softw Maint Evol Res Pract 18(2):83–107CrossRefGoogle Scholar
  21. Dig D, Negara S, Mohindra V, Johnson R (2008) ReBA: refactoring-aware binary adaptation of evolving libraries. In: Proceedings ICSE ’08. ACM, New York, pp 441–450Google Scholar
  22. Dmitriev M (2002) Language-specific make technology for the Java programming language. In: Proceedings OOPSLA ’02. ACM, New York, pp 373–385Google Scholar
  23. Drossopoulou S, Wragg D, Eisenbach S (1998) What is Java binary compatibility? In: ACM SIGPLAN Notices, vol 33. ACM, pp 341–361Google Scholar
  24. Forman IR, Conner MH, Danforth SH, Raper LK (1995) Release-to-release binary compatibility in SOM. In: Proceedings OOPSLA ’95. ACM, New York, pp 426–438Google Scholar
  25. Gosling J, Joy B, Steele G, Bracha G, Buckley A (2012) The Java™ language specification, 7th edn. Oracle, Inc., CaliforniaGoogle Scholar
  26. Henkel J, Diwan A (2005) Catchup! capturing and replaying refactorings to support api evolution. In: Proceedings ICSE’2005, pp 274–283Google Scholar
  27. Hoare CAR (1969) An axiomatic basis for computer programming. Commun ACM 12(10):576–580CrossRefzbMATHGoogle Scholar
  28. Hong NC (2013) Choosing a repository for your software project.
  29. Jezek K, Holy L, Slezacek A, Brada P (2013) Software components compatibility verification based on static byte-code analysis. In: SEAA, 39th EUROMICRO, pp 145–152Google Scholar
  30. Keller R, Hölzle U (1998) Binary component adaptation. In: Proceedings ECOOP ’98, vol 1445. Springer, pp 307–329Google Scholar
  31. Lehman MM, Belady LA (eds) (1985) Program evolution: processes of software change. Academic Press Professional, Inc., San DiegoGoogle Scholar
  32. Lindholm T, Yellin F, Bracha G, Buckley A (2012) The Java™ virtual machine specification—Java™ SE 7 edition. Oracle Inc.Google Scholar
  33. Mens T, Fernández-Ramil J, Degrandsart S (2008) The evolution of eclipse. In: Proceedings ICSM’08, pp 386–395Google Scholar
  34. Meyer B (1992) Applying ‘design by contract’. Computer 25(10):40–51CrossRefGoogle Scholar
  35. OSGi Alliance (2010) Semantic versioning technical whitepaper revision 1.0, Accessed 27 March 2014
  36. Preston-Werner T (2010) Semantic versioning 2.0.0. Accessed 27 March 2014
  37. Pukall M, Grebhahn A, Schröter R, Kästner C, Cazzola W, Götz S (2011) Javadaptor: unrestricted dynamic software updates for java. In: Proceedings ICSE’11, ICSE ’11. ACM, New York, pp 989–991Google Scholar
  38. Raemaekers S, van Deursen A, Visser J (2012) Measuring software library stability through historical version analysis. In: 2012 28th IEEE international conference on software maintenance (ICSM). IEEE, pp 378–387Google Scholar
  39. Raemaekers S, van Deursen A, Visser J (2014) Semantic versioning versus breaking changes: a study of the maven repository. Technical report, Delft University of Technology, Software Engineering Research GroupGoogle Scholar
  40. Robertson I (2013) The science and art of backwards compatibility. JavaOne 2013. Accessed 27 March 2014
  41. Savga I, Rudolf M (2007) Refactoring-based support for binary compatibility in evolving frameworks. In: Proceedings GPCE ’07. ACM, New York, pp 175–184Google Scholar
  42. Tempero E, Anslow C, Dietrich J, Han T, Li J, Lumpe M, Melton H, Noble J (2010) The Qualitas Corpus: a curated collection of Java Code for empirical studies. In: Proceedings APSEC’2010. IEEE, pp 336–345Google Scholar
  43. The OSGi Alliance (2012) OSGi core release 5.

Copyright information

© Springer Science+Business Media New York 2015

Authors and Affiliations

  1. 1.School of Engineering and Advanced TechnologyMassey UniversityPalmerston NorthNew Zealand
  2. 2.Faculty of Applied SciencesUniversity of West BohemiaPilsenCzech Republic

Personalised recommendations