Unlike many other language or compiler systems, Java doesn't link all your code into one big, freestanding program. Instead, it leaves everything in separate classfiles. Packages, and hence directory paths, impose some order on that. The JDK always knows where to find the Java run-time library classes, but the run-time class loader still needs to know where to find your classes.
The first point to note is that you can zip all your class files into a jar file, so you don't really need umpteen levels of directory on the customer's system. A jar file (Java Archive) works exactly like a zip file and can be used to store a whole directory tree in a single file. You can put other files that the application needs, such as image files, sound files, and translations for Strings, in the jar, too. Then you have to put the jar file (or the complete directory tree) where Java can find it, or tell Java the possible places to look for it. You can even set a jar file up so it will execute when its icon is double-clicked.
You can create your own jar files by using standard WinZIP, other software, or the jar utility that comes with the JDK. The jar program has a command line that looks like this in general form:
jar [ options ] [manifest] destination input-file [input-files]
The options that jar takes are similar to those of tar—the Unix tape archive utility—but the formats are different, and tar files are not used in Java. To create a compressed archive of all the class files and .jpg files for package a.b.c, you would use the commands
cd parent-of-a
jar cvf myJarFile.jar a/b/c/*.class a/b/c/*.jpg
Don't forget that once you put some code in a jar, it's not enough to recompile when you change something. You must also rebuild the jar file with the new .class; otherwise, you'll continue to get the old version of the program. Don't encrypt the jar file. Since JDK 1.2 there has been an option to update (replace a file in) an existing jar file. The example below shows how to replace the file Foo.class in archive myJarFile.jar.
jar u myJarFile.jar Foo.class
The directory pathnames stored inside the jar must match the package names exactly, with no extra or missing qualification. The pathnames are case sensitive within a jar file, and must exactly match the case of package, file, and class.
You can even make a jar file double-clickable, so that the application it contains will run automatically. This is a function of the file-to-program associations of the operating system, and you can find the procedures described at these URLs:
MacOS X: http://developer.apple.com/java/javatutorial/doubleclick.html
Windows: http://mindprod.com/jgloss/jar.html
If any of these move about, do a web search for “jar file double-clickable” combined with the OS or window environment name. There really ought to be a tool within the JDK to create double-clickable jar files automatically, by supplying another option to jar.
Java looks in the directory $JAVAHOME/jre/lib/ext for jar files. You can install your programs just by placing the jar file containing them in this directory. They will be found automatically without further action on the user's part. Now, this directory is reserved for use by the Java system, and it is intended for optional system libraries that weren't bundled with the JDK. However, it is super-convenient to put jar files there while you are learning about Java. Just don't do it for any deployed applications.
Java also looks in the directory $JAVAHOME/jre/classes for a directory hierarchy containing class files that corresponds to your package hierarchy. You may have to create the classes subdirectory the first time. If your program doesn't use packages, you can just dump the .class files directly in this directory. That gets messy for more than a few files, though.
The JDK will look at the CLASSPATH environment variable to know where to look for top level packages/directories. CLASSPATH tells the class loader all the possible places (roots) to begin looking for Java packages to import in a compilation or to load at run-time. Other Java compiler systems may use other arrangements, and their documentation will give the details.
You set CLASSPATH to be a list of all the directories where the JDK should start looking for your top level package/directory names. For class a/b/c/D.java, we would set CLASSPATH to contain the parent directory of “a”, and any other parent directories that contain the start of a package/directory path. Environment variables are shell and operating system specific, and the appendix that explains how to install the JDK also explains how shell variables are set, and how directory names are separated in the list.