If Java is the Answer, What Was the Question?
 
 

David Eichmann

School of Library and Information Science & Dept. of Computer Science

University of Iowa
3087 LIB
Iowa City, IA 52242

Tel: (319)335-5715, fax: (319)335-5374
Email: david-eichmann@uiowa.edu

URL: http://mingo.info-science.uiowa.edu/eichmann/
 
 
 
 
 
 

Abstract

Java propogates the flash and buzz of the Internet craze into the domains of software development and reuse.  This position paper briefly explores Java's potential from the perspective of software reuse and poses a (only somewhat) tongue-in-cheek question: Given Java, does the reuse community have anything left to do?
 

Keywords: abstraction, packaging, decoupled architectures, patterns

Workshop Goals: To establish a fresh direction for reuse that builds upon decentralized, decoupled architecures.

Working Groups: Distributed Architectures.
 
 

 1 Background On this, the tenth meeting of fellow WISRards (or is it the ninth? are we counting from zero like good computer scientists?), we find ourselves bested at our own game of exhorting the software community to reuse, REUSE, REUSE! Sun Microsystems came along with a language named after a funky, not-so-little island in the South Pacific and changed all of the rules...  Suddenly everyone is talking about APIs, beans, components - well, you get the idea.  With the (wired) world finally practicing what we've been preaching, what do we do now, er, next?
 
  2 Position The software community is ripe for reuse picking, if we can just figure out how to capitalize on the buzz created by Java.  From the ubiquity of the virtual machine to the dynamic configurability of for-name class loading, designers and coders have more features and tools available to support the culture and technology of reuse than they really know what to do with.
 
 

3 Approach

Java and its supporting runtime environment is rich with features investigated by the reuse community. Like C before it, the language itself is small, compared to the total vocabulary used by an average programmer.  Indeed, at the statement level, Java feels like C, picking up some of that language's quirkiness (how often to you count++ rather than count = count + 1?), while avoiding most of the resulting obfuscation (ever try to explain the distinction between ++count and count++ to a typical freshman?).
Here are a few of the language features and APIs that support reuse:

3.1 The Language: Concrete Classes, Abstract Classes & Interfaces The utility of inheritance for reuse has been clearly understood for a long time [Booch86, Meyer88]. The ability to extend existing program structure in a minimal and maintainable manner is clearly reflected in Java's choice of single inheritance. The supporting features of abstract classes and interfaces further enhance 'small scale' reuse by supporting a form of genericity and a mixed form of genericity and inheritance, respectively. 3.2 Modularity & Kits: Classes, Packages, JARs and Beans The simple notion of a class, coupled with Java's notion of a class path for runtime loading provides the degree of modularity found in most programming languages.  Exposing differing implementations of a given class signature on the class path at execution time results in potentially differing behavior, without sacrificing the desirability of strong typing. JARs (Java ARchives) provide a form of packaging that supports both ready distribution of code to (re)users and a more efficient means of remote execution by reducing the number of load requests necessary to get an applet running.  Java Beans take packaging of components even further, providing a standard mechanism for specification and generation of subsystems, including repackaging (serialization) of customizations by middleware, such as end user development environments.
  3.3 Architecture and Adaptation: Observer/Observable, For-Name Loading, Reflection, ... One of the most significant architectural design choices that we made in converting the MORE repository system [Eichmann98] from a C / CGI architecture to a Java applet / application was the selection of the Java library implementation of the Observer/Observable pattern.  The subsequent decoupling of data model, user interface, and management of persistence has resulted in the construction of a system that is both repository and component.  We can run-time parameterize the system through, for example, the designation of a particular JDBC interface, and load that interface by its name at run-time, supporting ad hoc composition of systems.

The Java Reflection API provides powerful mechanisms for development tools to 'introspect' a component such as MORE, discover those aspects available for customization and the interfaces through which the component can be manipulated.  This technology holds great promise for future approaches to dynamic formulation of system architectures [Sametinger97] such as those solicited by NSF for the Next Generation Software initiative.
 

4 Comparison

It is not my intention to claim that with the advent and popularity of Java, research into programming languages becomes moot.  Indeed, who would have thought as recently as three years ago that an upstart language designed by a single commercial organization could have achieved the acceptance and market penetration that Java has?  Clearly, with the right appeal, new languages can gain broad usage.  If anything, Java argues that language development offers great potential to shape the thinking and expression of the software development community.

Much of Java's potential involves not the language per se, but rather what a common framework of this flexibility and expressiveness can mean for compatible, collaborative research.
 
 

References

[Arnold98] Arnold, Ken and James Gosling, The Java Programming Language: Second Edition, Addison Wesley, 1998.

[Booch86] Booch, Grady, "Object-Oriented Software Development," IEEE Trans. of Software Engineering, Vol. SE-12, No. 2, February 1986, pp. 211-221.

[Eichmann97] Eichmann, David, "Representing Knowledge in Domain Engineering," WISR-8, Columbus, OH, 23-26 March, 1997.

[Eichmann98] Eichmann, David, MORE repository system, http://marengo.info-science.uiowa.edu/MORE/.

[Lea97] Lea, Doug, Concurrent Programming in Java: Design Principles and Patterns, Addison-Wesley, 1997.

[Meyer88] Meyer, Bertrand, Object-Oriented Software Construction, Prentice Hall, 1988.

[Sametinger97] Sametinger, Johannes, "Component Interoperation," WISR-8, Columbus, OH, 23-26 March, 1997.

[Symantec98] Symantec, Inc., Visual Cafe for Java, Cupertino, CA, 1998.
 

 Biography

David Eichmann (david-eichmann@uiowa.edu) School of Library and Information Science & Dept. of Computer Science, University of Iowa, Iowa City, IA 52242, http://mingo.info-science.uiowa.edu/eichmann/

I am an Assistant Professor of Information Science in the School of Library and Information Science, with a joint appointment in the
Department of Computer Science.  Before returning to the University of Iowa in the fall of 1997, I was an Associate Professor and Chair of
Software Engineering at the University of Houston - Clear Lake and Director of Research and Development of the Repository Based Software
Engineering Program (RBSE), where my responsibilities included management of a fifteen person research and development group working in the
areas of reuse / reengineering and Internet resource discovery.  The work on the MORE repository system resulted in the RBSE development team being nominated by Johnson Space Center for the 1998 NASA Software of the Year Award.  We didn't win...