Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-) Softpanorama Search

Softpanorama Java Bulletin, 2000

Creating a Classpath By S. Lee Henry

After struggling for hours with some problems that ultimately boiled down to an insufficient Java classpath, I learned how to create a path statement on the fly. For anyone not familiar with Java and not wishing to be, the technique that I used might prove useful since it can be applied to other Unix paths as well.

One of the reasons that I needed to develop a clever approach to creating my java.classpath relates to a limitation on Unix systems. The vi editor doesn't seem to appreciate lines exceeding 2,000 characters (or thereabouts). I was having problems with the single line in my jsm.properties file that defines the java.classpath -? the classpath that JRun uses to process Java code. Since I could not directly edit the line, the best approach seemed to be to disassemble and rebuild it. The tool that I chose for the task was the Unix tr (translate) command.

Like most, if not all, paths in Unix, colons separate java.classpath elements. A java.classpath might look like this:

    java.classpath=/usr/java1.3/lib/jsp.jar:/usr/java1.3/lib/wcca.jar

In my case, the classpath included many more elements. It had, in fact, more than 100 elements for one particular system. To make the line that defined the path accessible for editing, I ran the file through a tr filter like so:

    boson% cat jsm.properties | tr ":" "\012" > hold.$$

This command created a file in which every element in my classpath was on a line by itself. This enabled me to change or remove lines as needed, and to add elements that were missing. If my java.classpath looked like the example shown above, after this manipulation, it would have looked like this:

    java.classpath=/usr/java1.3/lib/jsp.jar
    /usr/java1.3/lib/wcca.jar

When I finished my editing, I added a colon back to each line using this vi command (from the line where the "java.classpath" line began:

    :s/$/:/105

This added a colon to the end of the current line and the following 104 lines. Since I wasn't sure if the classpath would be valid if it ended in a colon, I avoided adding a colon there. It would have been nearly as easy to remove an extra colon and I wouldn't have needed a line count.

On another system, I went even further. I created a java.classpath completely from scratch by first collecting a list of all of the jar files on the system using a find command such as this:

    boson% find / -name "*.jar" -print > jarfiles

I also looked for files ending in .zip since these might also be Java files.

    boson% find / -name "*.zip" -print >> jarfiles

I then reviewed the contents of my jarfiles file to make sure any zip files that I included related to my Java application. After checking the entries my jarfiles file, I added "java.classpath=" to the top and then proceeded to turn this file into a single line, again using the Unix tr command.

    boson% cat jarfiles | tr -d "\012" >> jsm.properties

This removed all the linefeeds from the file, but left the appended line without a linefeed. The final step was:

    boson% echo "" >> jsm.properties

I then had a single line defining my java.classpath at the end of my jsm.properties file. I restarted JRun and everything ran fine after that. I like happy endings. Don't you?

"The two methods for creating persistence (reloading and pseudo-constructors) cooperate beautifully. Our shopping cart, for instance, is created once, and then never destroyed. Applet reload gives it continuing access to the underlying HTML, through Javascript and LiveConnect, and through the applet lifecycle, which can pass current context information to the persistent class."  

"The Open Source shopping cart solves these problems. It comes in two versions-- one for the small web designer, the other for the large company. We will first examine the small business version."