Java and Its Usefulness in Libraries.

by Zach Tomaszewski

for LIS 699, Spring 2001, supervised by Dr. Larry Osborne

After completing the ICS111 introductory course in Java, I'd say Java certainly has its applications, both in libraries and elsewhere.

Java is object-oriented, which means it is very modular. Parts of programs can be tested independently, making debugging easier. Parts can be reused in other programs or in different parts of a large program. This makes big projects, such a writing an entire library catalog system, much easier. It also makes collaborative programming simpler, as each programmer can work on a separate module then put all the pieces together at the end. The down-side is that the programmers must understand how to write good object-oriented code.

Java is also strongly typed, which means it is difficult to abuse variables or to produce odd results based on syntax or the context of an expression. This, along with the object-oriented aspect, means that there is a lot of programming overhead: defining classes, declaring variables, resizing arrays, etc. Also, the compile-then-run nature of Java makes debugging slower. Precisely those things that are a benefit for large projects are a hinderance for quick fixes and small jobs.

Java's platform-independence is a nice feature. This means that a library could change its hardware and still use the same Java programs with little trouble, provided there is a Java Virtual Machine written for the new hardware. Platform-independence makes Java ideal for web-based applications, which is an important consideration these days.

The most obvious use of Java in libraries would be for a writing a catalog/circulation system. It is possible that every item on the physical shelves could be modeled in the system. Every copy of a book or periodical would have its own corresponding object. The same would apply to patrons. Using instance variables, book objects could be reciprocally linked with borrower objects.

The system would likely contain a class for every type of resource, such as Book, Video, Periodical, Map, etc. Maybe these would all be subclasses of the PhysicalItem class. Other classes would be used for online resources and such. Each class would likely define instance variables for cataloging information; perhaps each variable would correspond to a MARC field. Those items that can be checked out (as opposed to reference materials) could implement a CheckOutAble interface. A system would only have to include those classes that the library needs to represent their materials; a library with no maps would not need the Map class.

Though these kinds of objects make the most sense when it comes to keeping track of circulation, the same information would have to be used for searching the catalog. There is a variety of ways this could be done. One is to simply query every object for the appropriate information, such as its title, and search iteratively. This would be incredibly slow. The objects could be ordered in a variety of different linked lists or arrays to allow for binary searching, but this still seems a poor choice since there would be redundant copies of the same work and no authority control. A better option would be to search AuthorityFile or keyword Index objects, which would then link to the PhysicalItem objects. Again, the searched objects would have be kept in a sorted order to speed the searching.

These puzzles and design issues are fun to ponder. But these are really only programmer issues. In the end, the library probably couldn't care less. As long as the system is affordable, stable, usable, and efficient, they'll probably be pleased. For that, they should look for good programmers and companies with reliable customer service records before looking for a system written in Java.

I am very glad I took this course and enjoyed learning the basics of Java. Besides how to write good Java code, I think I have gained a grasp of the strengths and weaknesses of the language. I hope to continue developing my skills, both in Java and object-oriented databases.