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

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

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?

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.

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:

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.

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.

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.

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.

[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.

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

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

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