Detecting Entry Points in Java Libraries

  • Thomas Baar
  • Philipp Kumar
Conference paper
Part of the Lecture Notes in Computer Science book series (LNCS, volume 7162)


When writing a Java library, it is very difficult to hide functionality that is intended not to be used by clients. The visibility concept of Java often forces the developer to expose implementation details. Consequently, we find a high number of public classes and methods in many Java libraries. Thus, client programmers must rely on documentation in order to identify the entry points of the library, i.e. the methods originally intended to be used by clients.

In this paper, we introduce a new metric, called the Method Weight, that assists in detecting entry points. Applying this metric on some well-known open-source Java libraries considerably supported the process of identifying their entry points. Furthermore, the metric provides a classification criterion to distinguish libraries with focused functionality from plain collections of utility classes.


Entry Point Method Weight Code Size Visibility Concept Public Method 
These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.


Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.


  1. 1.
    Apache Foundation: Byte Code Engineering Library (BCEL) 5.2,
  2. 2.
    Apache Foundation: Commons IO Library 2.0.1,
  3. 3.
    Bloch, J.: Effective Java, 2nd edn. Addison-Wesley (2008)Google Scholar
  4. 4.
    Chidamber, S.R., Kemerer, C.F.: A metrics suite for object oriented design. IEEE Trans. Softw. Eng. 20, 476–493 (1994), CrossRefGoogle Scholar
  5. 5.
    Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading/MA (1995)Google Scholar
  6. 6.
    Gosling, J., Joy, B., Steele, G.L., Bracha, G.: Java Language Specification, 3rd edn. Addison-Wesley (2005)Google Scholar
  7. 7.
    Halstead, M.H.: Elements of software science. Elsevier (1977)Google Scholar
  8. 8.
    Henning, M.: API Design Matters. Communications of the ACM (CACM) 52(5), 46–56 (2009)CrossRefGoogle Scholar
  9. 9.
    Java Community Process: Java Specification Request (JSR)-294,
  10. 10.
    Kerievsky, J.: Refactoring to Patterns. Addison-Wesley (2005)Google Scholar
  11. 11.
    Knoernschild, K.: JarAnalyzer 1.2,
  12. 12.
    Lafortune, E.: ProGuard 4.6,
  13. 13.
    McCabe, T.J.: A complexity measure. IEEE Transactions on Software Engineering 2(4), 308–320 (1976)MathSciNetzbMATHCrossRefGoogle Scholar
  14. 14.
  15. 15.
    OSGi Alliance: OSGi Service Platform Release 4.2 (2010),
  16. 16.
    Parnas, D.L.: On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 1053–1058 (1972), CrossRefGoogle Scholar
  17. 17.
    Spinellis, D.D.: ckjm 1.9 — an implementation of the Chidamber and Kemerer metrics for Java,
  18. 18.
    Tulach, J.: Practical API Design: Confessions of a Java Framework Architect. APress (2008)Google Scholar

Copyright information

© Springer-Verlag Berlin Heidelberg 2012

Authors and Affiliations

  • Thomas Baar
    • 1
  • Philipp Kumar
    • 1
  1. 1.akquinet tech @ spree GmbHBerlinGermany

Personalised recommendations