Abstract 

The Java programming language has some special implications for library technologies including but not limited to: software distribution, off-line searching and data manipulation, maintenance reduction, sophisticated database interaction and user interface design. Java-related technologies, such as Castanet, offer a convenient way for libraries to push information to information seekers, anticipating their needs based on their own professed interest areas. This paper will very briefly introduce Java and then show how the distributed object-oriented language might be used to address current and developing library applications. This paper does not address the question of whether libraries should emulate the partnership of Barnes & Noble and Starbucks, but that omission should not be construed as a vote again such partnerships. 

What is Java?

According to the developers of the Java Language, Java is: 
simple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose programming language. Java supports programming for the Internet in the form of platform-independent Java applets. 

Put more simply Java is a new generation programming language that was designed with the benefit of the knowledge of the points of failure from previous languages. It takes full advantage of new operating systems. It removes many of the restrictions placed on the programmer by earlier languages and earlier assumptions about hardware and performance. From its very beginning, Java was designed to allow code to be reusable so that you need only solve a problem once (or find someone who has already solved it to your satisfaction). Further, since Java is object oriented, Java classes may be extended rather than completely rewritten, allowing programers to easily build on the experience of others. Java, in its Web incarnation as applets, was designed from the beginning with security in mind so that Java's access to your data and to sensitive parts of your machine is restricted. 

Java was designed as a way to program very small portable computers and PDAs (or portable digital assistants), then set-top boxes, and finally on virtual machines--computers emulated by software so as to present the same functionality and operability regardless of the underlying hardware--embedded in applications such as Netscape or burned into real honest-to-goodness Java chips. Since the Java machines all behave the same--are bug-for-bug compliant, some would say -- code written and tested on any Java platform should perform identically. That is, Java code is completely portable between Java machines, virtual and otherwise. Java programs may be delivered easily across the Internet. 

When I'm asked just who is Java good for I answer: 

1. Java is a boon to programmers as it allows cross-platform execution, code security, object development. 
2. Java is a boon to HTML developers as it allows them to add animation, interaction and customization easily. 
3. Java is a boon to network managers as it decreases the need for helper applications as well as the need to keep them up to date, virii free, and registered. 
4. Java is a boon to end users in that they don't have to worry about any of the above. We just turn on our computers and do the work we need to do.

I would add that Java is great for database developers as it allows for quickly customized clients to be delivered on demand and a great database interface through the JDBC. 

So what does this mean for libraries: digital and otherwise? It means improvements and opportunities in the areas of clients, servers, databases, maintenance, access, and a creation of new library services that might anticipate the needs of those who use our resources. 

Clients--more than CGI, more than WWW

In the beginning the World Wide Web was designed to deliver pages of textual information; interactivity with the pages other then reading and clicking to other pages wasn't well intergrated into the design. Pages that did extend interactivity were done on the server side through an interface now known as CGI or Common Gateway Interface. The best you could hope for for client interaction was to fill out a form full of information and to submit it to the server where the information could be processed and some kind of results returned to the client. While this is fine form some purposes and was in fact what most computer interaction had been in the past, most designers, programmers, and users found that they needed more intelligence at their fingertips, that is in their clients. Why? Because CGI usage means that you wait and you wait on the server and on the network. 

Java programs allow the client to interact without further server interaction. The program and the data are on your own personal machine resulting in smoother interaction and faster processing. A Java applet, as small Java programs running on a WWW browser virtual machine are called, might allow you to rotate a 3-D vase or molecule. It might allow you, in one of my favorite cases, to rearrange tiles of words on a page as you would refrigerator magnet poetry. 

Libraries designing clients that need to use interactivity whether that interactivity is in the form of live interactive image maps, audio feedback for the visually impaired, language learning games for children, or enhancing access to library resources will find that Java will remove many of the barriers that they have faced in the past when working with the World Wide Web. 

But wait! You don't even need to use the World Wide Web to use Java. Java applications, those Java programs that do not run exclusively on the virtual machine of a WWW browser, may be distributed by other means than WWW--say FTP, copied from a disk or CD, run from a local are network, or received by Castanet (of which we will read more about later in this paper). The WWW browser wisely requires a much more secure and thus more restricted environment for its applets. Applications are allowed to write to your disk, for example, which you may well wish to do when you are say annotating an image of a cave painting. 

Even better, you can use the same code for an applet and for an application. Java is object-oriented and reusable afterall. In our image annotation example, the same code might be used to create the annotations of the cave painting as an application and as an applet, people all over the world might use the WWW to view the cave painting and its annotations. 

Servers--more flexible servers, more interoperability

When HTTP servers were first deployed, computer scientists sneered that an undergraduate could write such a server in one afternoon. That was, of course, the beauty of the early servers; they didn't do much but they were fast and reliable. But as the WWW has grown, we demand much more for servers. We want even more speed, more interactivity with our databases, with our programs on our server machines and with documents on our servers. 

Servers written entirely in Java, such as Jigsaw and JeeVes, offer the flexibility of Java and object oriented programs. First, such servers are easily customizable and extendable without requiring changes to their distributed code. Second updates are simple to install (and to remove) makes upgrades an extremely simple task and decreasing server down time. Third, Jigsaw and JeeVes take advantage of the object concept in innovative ways. 

Let's focus on Jigsaw for a moment. Jigsaw introduce some important improvements to HTTP servers: 

1. Document caching as persistent objects so that the server need not seek and read documents from disk at each request for those documents. Think of it as a server that can remember.
2. The server can also remember information about a document such as the security level required to access it, thus reducing accesses of configuration files and reducing authentication replication.
3. Jigsaw allows both document retrieval and document posting into Web space, a very handy feature in creating guest books and dialogs. Since Jigsaw stores the documents that it serves in its memory, this feature could be used to create reader communities and reader discussions revolving around library materials.

Java servers can more easily interoperate with other Java programs running on the same machine as the servers due to their object orientation. Thus, new features could be added to the server in a rather seamless way. Client pages might be created on the fly based on a profile that the user creates for herself so that when we ask the search engine to search for "similar" records that we (or at least the server) have some idea of what "similar" means in this request. In this way, a Java server can assist in the building of agents that may someday become intelligent. 

Databases--better interfaces, better access

Just as the Java virtual machine allows Java code to operate the same on a Cray, a MacIntosh, a Sun or a PC running Windows 95, the Java database access code, called the JDBC or Java Database Connectivity, allows programs written in Java to access any ANSI SQL-2 standard database. 

SQL stands for Structured Query Language; it has been in use for more than twenty years and in theory allows access to most databases currently in use While SQL was invented for accessing IBM databases on large mainframes, it is also used for accessing databases on single PCs. 

Having a standard for query language, the language which a program uses to make requests of a database, is extremely helpful, but the code or driver for passing that request to the database and receiving the answer must also be in place. ODBC, Open DataBase Connectivity, was created by Microsoft to allow common connectivity between such applications as Excell, FoxPro, Btrieve and such databases as Oracle, Paradox and IBM back-end databases. Besides implementing SQL, Java also includes a bridge that allows access to ODBC back-end databases. 

While the combination of the JDBC and the ODBC driver sound complex, they are much easier to use and to implement in programs than custom C code and they allow the program to be used across the wide variety of vendors' database products. Still, each transaction requires a chain of interactions which, by their nature, are more ineffecient than a completely native implementation of the same transaction. 

Why then use the JDBC? Because it allows your applications to present the same interface to all databases current and future on all platforms. It allows back-end database software to be upgraded or completely changed without any impact on the appearance of the client interface and without any user retraining. An application that accesses an Oracle database on your server could also be used to access a MS Access database on your local PC with no changes to the code, for example. And thanks to Java, local GUI designers who understand their businesses needs can create really usable client software for all platforms. 

Off-line too!

Much has been made of the fact that Java applets and applications are easily distributed on the World Wide Web, but one shouldn't forget that Java works just fine off-line too. Part of the joy of Java is that the applets and applications run on your own machine rather than rely on a server or CGI script. This means that once a Java application is on your machine, you can work with it as you need. Unless it is dependent on files or programs elsewhere on your network or on the Internet, you do not need a network connection of any type to use it. You can take your laptop to the end of your dock, on your sailboat, or simply out in the garden, and work when you should be relaxing. 

Your only real concern might be that you have the latest version of the application on your machine. Until recently, your systems or network manager would be responsible for making sure that everyone in the organization was informed about the latest release of each application that they wanted to run locally or off-line. And then each user of each computer would have to download it to their own machine. I don't have to tell you that this one problem consumes more of the most important time in every organization -- your own. 

Pushing with Java and with Castanet

What you would really like to have happen is for a program on your computer to talk to the server on which new applications reside. That program would listen to the server for announcements of new versions of applications that you wanted on your local machine. When the server did have an update, that program would request the new version and install it for you. Ideally, all of this would not happen when you start up your machine, but a various times during the day when your computer was idle. To take this one step further, it might not even download the whole application, but only those parts, those objects that have changed. 

What I have described above is not from Tomorrowland, but it is a description of Marimba's Castanet. The local program is call the tuner, like a radio tuner. The tuner can be told to listen for announcements from trusted servers. Trust is important to avoid getting virii or trojan horses, whether getting applications written in Java or anyother language. 

This one feature can greatly reduce the amount of time, energy, and patience spent in keeping both staff and public computer access up to date and working well. For libraries with public access computers, this will be an immediate boon especially when (and I predict fairly soon) WWW browsers and helper applications are written in Java. No more rushing around to be sure that some new plugin or application is installed on each machine, or on the other hand, facing the wrath and indignation of a public or staff that insist that the network manager be aware of every new data format. Already Java applets are downloaded and discarded as needed, Castanet makes that same flexibility available to applications. 

This kind of technology will be essential for the new Java stations or network computers. 

What's the downside?

If all this Java stuff is so wonderful, why isn't it everywhere? 

First, Java has had the fastest adoption rate of any new computer language so far. So it will be everywhere soon, or so it seems. But the fact is that it is not. Older systems, those running DOS or older versions of Windows, cannot or do not have a Java virtual machine and so will not run Java applications or applets. True, computers are moving fast and older computers are left behind, but those older computer often sit in libraries--or on my desk. 

Second, Java is a new computer language, and as a result there are not that many programmers with a lot of experience in Java. True it is easier to learn than C++, but if you have already learned C++, that is not an issue. Since Java is a new language, the applications written in Java are not fully mature as say Word. Of course, Word may be over mature and too feature rich by now for some. For better or worse, Java applications have a ways to go to catch up. 

Third, performance is improving for the Java virtual machine, and more Java native code machines are becoming available. That is a nice way of saying that Java performance is not up to that of C. New techniques, such as just-in-time compilers for Java, have helped out, but there is more work to be done. 

Fourth, Java development environments are improving and being intergrated into new products everyday including GUI development tools, a C++ environment called J++, and even the promise of a Macromedia Director Java translator. This is a nice way of saying that Java is a new language and so the development environments are still in the process of refinement and deployment. 

Lastly -- and this is becoming less a problem as time passes -- since Java is a new programming language, the virtual machines are not yet purely bug-for-bug compatable. 

Most all of the problems I've described above are directly attributable to the newness of Java. And I, for one, have been amazed at how quickly progress hase been made toward solving each of them. 

A conclusion

Java is the obvious choice for software development for new library applications and for distributed applets on the Internet. Java is increasingly integrated into development environments, into WWW browsers, and into operating systems. Additionally Java is the obvious choice for developers for the new NCs (network computers). Java APIs (application program interfaces) are being developed, even as I type, to extend the power of Java programming to new areas including Internet telephony and wireless applications. At the moment and in the near future, Java faces no serious competition as an object-oriented language. 

When making a decission about a programming language, just say "Java." 

Further readings

JavaWorld Magazine - Strictly Java and all on-line with good technical articles and examples 

Java-related newsgroups

Cafe Au Lait - Continuously updated Java FAQ (not by SUN) 

Java Tutorial - Very useful online version of the popular book (the book is a good buy too). 

Just Java by Peter van der Linden - recommended to me by an employee who told me later that "this is a good book for not-so-serious programmers like you managers"; it is a good book despite his quip. 

Java in a Nutshell - from the ever popular O'Reilly Nutshell series. A good reference but be ready to read and write code. 

Java Programming for the Internet - Applet-oriented programming (I know the authors but I receommend the book anyway). 

Copyright © 1997 Paul Jones

hdl:cnri.dlib/march97-jones