Advertisement

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)

Abstract

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.

Keywords

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.

Preview

Unable to display preview. Download preview PDF.

Unable to display preview. Download preview PDF.

References

  1. 1.
    Apache Foundation: Byte Code Engineering Library (BCEL) 5.2, http://jakarta.apache.org/bcel/
  2. 2.
    Apache Foundation: Commons IO Library 2.0.1, http://commons.apache.org/io/
  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), http://portal.acm.org/citation.cfm?id=630808.631131 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, http://jcp.org/en/jsr/detail?id=294
  10. 10.
    Kerievsky, J.: Refactoring to Patterns. Addison-Wesley (2005)Google Scholar
  11. 11.
    Knoernschild, K.: JarAnalyzer 1.2, http://www.kirkk.com/main/main/jaranalyzer
  12. 12.
    Lafortune, E.: ProGuard 4.6, http://proguard.sourceforge.net/
  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), http://www.osgi.org/Download/Release4V42
  16. 16.
    Parnas, D.L.: On the criteria to be used in decomposing systems into modules. Commun. ACM 15, 1053–1058 (1972), http://doi.acm.org/10.1145/361598.361623 CrossRefGoogle Scholar
  17. 17.
    Spinellis, D.D.: ckjm 1.9 — an implementation of the Chidamber and Kemerer metrics for Java, http://www.spinellis.gr/sw/ckjm/
  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