I recently taught a round of workshops, and was asked many questions about Java. There’s a lot of confusion about what it is, what it does, and how it relates to the library environment. In this column, I’ll present a basic introduction to Java and then look at its use in commercial products for libraries.
Just a Programming Language
Java is a tool for programming computers--a programming language. Like its predecessors, FORTRAN, Pascal, and C, Java tells computers what we want them to do. Its main characteristics are that it’s object-oriented and relies on reusable blocks of code called "classes."
While Java is just a programming language, it’s one that has proven to be exceptionally well-suited for the development of Web-related programs. Java was invented by Sun Microsystems, and provides a powerful and flexible approach for creating software that operates on a wide variety of hardware devices--not only computers, but other devices that we might want to communicate with and control. In the Web environment especially, you don’t know what kind of computer your users might have, so it’s critical to write applications that are independent of specific computer operating systems. Today, the majority of the programs that power the commercial Web have been developed using Java.
The Java Virtual Machine
One of the benefits of Java is its ability to operate in a variety of computer environments. Other programming languages, such as C, need to be written and compiled specifically for each operating system in which they’ll be used. The compilation process takes the human-readable programming language code and creates an executable program that the computer can understand. The differences among operating systems usually mean that changes to the program must be made before it will compile and run on different kinds of computers. This approach to creating a program that will operate on multiple platforms--Windows, Macintosh, UNIX--can be a long and complex process. Java avoids this complexity by allowing one version of a program to run on all these different types of computers through the "Java Virtual Machine." This is a subsystem that can be incorporated into a variety of computer environments that becomes the space in which Java programs do their work.
Operating systems may not necessarily come with the Java Virtual Machine preinstalled. For computers used as servers, the Java Virtual Machine can be installed and becomes part of the operating system. A full-fledged Java Virtual Machine is provided for many operating systems through either a Java Development Kit (that includes tools for developing and running applications in Java), or through a Java Runtime Environment (that simply allows Java applications to run). A more limited Java Virtual Machine is featured in most modern Web browsers. For computers used as network servers running operating systems, such as UNIX, Windows NT, Windows 2000, and NetWare, the Java Development Kit or Runtime Environment is the standard approach for supporting Java applications. But for computers used as clients, the primary vehicle for providing the Java Virtual Machine is the Web browser. The recent versions of both Microsoft’s Internet Explorer and Netscape’s Navigator come with a Java Virtual Machine. Because of this, We b sites can include small applications-applets- written in Java that will run on practically any computer.
Playing in the Sandbox
One of the great concerns with running programs distributed on the Web is making sure that these programs aren’t allowed to do destructive things to computers. Since Java is a powerful language, a malicious programmer might write and put on a Web site a program that destroys information on its victims’ computers. Theoretically, this isn’t possible with Java. All Java programs must operate within a strictly defined environment called the "sandbox." You can play in the sand, but there are rigid boundaries that are off limits. This secure sandbox prevents Java applications from gaining access to the computer’s operating environment since there’s no direct access to the operating system, data files, or hardware devices. Java’s security architecture has been designed to preclude malicious programs, but it also places some limits on what can be done with Java programs in a Web environment.
An Enhanced Web Environment
As Web applications become more sophisticated, developers often find HTML to be too limiting. Many Web developers take advantage of JavaScript, a scripting language developed by Netscape, to enhance their Web pages. But JavaScript isn’t Java. While Java is a full, object-oriented programming language, JavaScript comprises a relatively small set of procedures that can be used within HTML documents to produce various special effects. Java applets, though they’re often launched from a Web page, run independently of any HTML document and have much more powerful capabilities. Java applets are able to do more sophisticated tasks than are possible using HTML and JavaScript.
Java for Libraries
While the dot-com world has embraced Java as its favorite programming language, the library world has been less aggressive in its adoption. However, there are some library companies that utilize Java in their products. Innovative Interfaces, Inc. uses Java for its graphical clients in its Millennium library automation system; epixtech, Inc. offers a Java version of its WebPac; and OCLC uses Java for the server side of its SiteSearch application.
Millennium
Innovative has long been one of the leading library automation companies. For many years, its INNOPAC system has been one of the most sophisticated and feature-rich integrated library systems on the market. INNOPAC, however, was created in a text-based host/terminal environment--an architecture that’s not well accepted in the current marketplace. Today, libraries expect an automation system that operates in a client/server model and that includes graphical clients able to take advantage of powerful, yet inexpensive computers. Some library automation vendors have had to adopt a revolutionary approach in modernizing their systems: They’ve created entirely new systems from the ground up. Companies such as DRA and VTLS have followed this approach. Innovative chose an evolutionary method with which to modernize INNOPAC from its original host/terminal environment into a client/server architecture. Rather than starting from scratch, Innovative has made gradual changes to its system overtime. The resulting Millenniu m system can certainly be considered to be a modern client/server application, though only a few steps distant in the technical evolution from its INNOPAC predecessor.
One of the defining characteristics of a client/server system involves graphical clients that provide the basic user interface. For a sophisticated application such as a library automation system, the types of features that must be incorporated into this interface can be quite complex. The vast majority of users have chosen to build their clients in the Microsoft Windows environment. Windows, at least for the time being, is the most pervasive desktop computing environment in both the home and workplace.
What’s unique about Innovative’s approach is that it has made this change through the use of client-side Java. Millennium is a very complex application. It relies on capabilities that aren’t available in the Java Virtual Machine that’s provided within browsers and requires the Java Runtime Environment. By using client-side Java to build its system, Innovative kept open its options to operate in other environments besides Windows. While the great majority of Millennium users do in fact run their staff clients through Windows, the possibility exists for it to run with other operating systems.
Innovative has recently had some success with implementing the Millennium system in environments other than Windows. Linux enthusiasts envision that particular operating system as one that could completely replace Windows--both for servers and as a desktop computing environment. Since there is a Java Virtual Machine available for Linux, it can support Java applications such as Millennium. In April 2000, Innovative announced that it would install Linux in Millennium. The Santa Clara (California) University Library was an early adopter of this approach, successfully using Millennium on desktop computers running Linux instead of Windows.
More recently, Innovative has been focusing on fine-tuning Millennium to work on Macintosh computers. In October, the company announced that it’s beta testing Millennium under the new Mac OS X--an implementation of the Macintosh operating system that incorporates more UNIX-like characteristics. With the advanced Java environment, libraries will soon be able to run Millennium on Macintosh computers. The Mac OS X is currently in beta testing, and is expected to be available early next year.
By implementing Java into its client software, Innovative Interfaces has made itself less dependent on Microsoft operating systems. While no one expects the popularity of Windows to decline anytime soon, libraries using other operating systems for their desktop computers will have additional options. [Editor’s Note: For more on Millennium, see the news story on page 51.]
The Java WebPAC
Epixtech uses Java in a different way. The company has created a version of its WebPAC as a Java applet that operates through the Java Virtual Machine. While epixtech also offers an HTML version of its WebPAC, the Java version offers more advanced capabilities and is more secure. The Java WebPAC allows library users to check their personal records and perform such tasks as renewing their books online. It’s more secure because it keeps each user’s search session private. With an HTML client, it’s often possible for a patron to use the history list or browser back buttons to view the activity of a previous user--a particular concern for libraries. The Java version doesn’t operate within the browser in the same way, and it protects the privacy of library patrons.
There’s a downside though. The Java WebPAC applet has to be downloaded into the browser. This is less of a problem for in-house library computers, but for remote users with slow Internet connections, the download can take a while. Printing can also be problematic. As we learned earlier, the Java Virtual Machine must live within a secure sandbox. Since the computer’s printer lies outside the sandbox, printing can be a little cumbersome. With the Java WebPAC, the print command sends its output to a new Web browser window, which then relies on the browser’s print functions; it can’t send output directly to the printer. Some libraries find this two-step printing process to be bothersome.
SiteSearch
So far, we’ve seen examples of full-blown Java clients in Millennium and Java applets in epixtech’s WebPAC. OCLC makes use of Java in a different way in its SiteSearch suite. SiteSearch is a complex environment that contains a variety of tools for creating interfaces to library resources. Some of its components include an advanced Z39.50 environment called WebZ that allows a library to provide access to information available from a wide variety of sources. It’s basically a highly customizable Z39.50 client with a Web gateway. As a Z39.50 client, SiteSearch can query multiple Z39.50 servers; collate the results; and present a unified, sorted set of results to the end-user. SiteSearch can also load or create local databases. I won’t go into all the features here, but suffice it to say it’s a very sophisticated application with powerful capabilities.
The characteristic of SiteSearch that I want to highlight here is that it’s built primarily with server-side Java. While earlier versions of SiteSearch were written in other languages, including a proprietary scripting language invented by OCLC, its most recent version relies almost entirely on Java. Not only are its basic programs constructed in this way, but Java is also the language that libraries use to customize SiteSearch for their own local applications.
SiteSearch works on a number of UNIX operating systems and requires the Java Development Kit. This approach allows SiteSearch to run on a wide variety of UNIX flavors such as Solaris, AIX, and Linux.
One of the main advantages--and disadvantages--of incorporating Java into SiteSearch is that libraries can use a standard, well-known programming language to create customized applications. With earlier versions, this process required the library’s technical staff to learn an obscure and complex scripting language. Now, they can do the same work with a widely used programming language. This is an advantage, since there are lots of programmers who know Java. This is also a disadvantage, because library staff members who learn Java often find more lucrative opportunities outside the library world once they have gained this skill.
Although SiteSearch uses Java for its server functions, that doesn’t mean it requires Java on the client side. Remember that Java is just a programming language. In the same way that server programs written in languages such as Perl, C, or C++ can operate in a pure HTML environment, the same is true with Java. OCLC has written SiteSearch so that all its Java programs produce standard HTML output. Web browsers don’t need to support Java to use applications created through SiteSearch.
Java--A Versatile Environment
While there may be other applications in the library environment that make some use of Java, Millennium, WebPAC, and SiteSearch are some of the best examples of the ways that Java can be used. We’ve seen that Java can be employed to create complex client applications, support applets that deliver information in ways too complex for HTML, and function as a server environment. It’s interesting that there is no library automation system that I’m aware of that uses Java for all these purposes. INNOPAC’s Web client uses HTML, not Java, and it doesn’t use Java for its server programs; SiteSearch uses Java for its servers, but not for client access. This indicates to me that while Java is beginning to make more of a presence in the realm of library automation, there isn’t necessarily an overwhelming trend toward using it. Like other technologies, Java is well-suited for many uses, but it’s not a panacea that will solve all the problems and complexities involved in creating Web-based applications in the library envi ronment.
Marshall Breeding is the technology analyst at Vanderbilt University’s Heard Library and a writer and speaker on library technology issues.
