Paul Jones
UNC's MetaLab
University of North Carolina
pjones@sunsite.unc.edu
D-Lib Magazine, March 1997
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.
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:
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.
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 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:
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.
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.
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.
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.
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.
When making a decission about a programming language, just say "Java."
Further readings JavaSoft home page - Home to all official Sun Java announcements and documentation
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).
hdl:cnri.dlib/march97-jones