Files must be located relative to one of the entries in the classpath, The code we prepared for this tutorial is in the tutorial.tcltk98 package, so the Java files need to be in the directory tutorial/tcltk98/ relative to one of the entries in the classpath.
The simplest way to set the classpath is to set the CLASSPATH environment variable. On Solaris, you might go:
setenv CLASSPATH .:/users/johnr/java(It is always handy to have the current directory "." in the classpath, as it allows you to create test classes wherever you are without having to worry about packages.) Now, this classpath will only work if none of our Java code reference the Tcl Blend java code in tcl.lang. If it does (which it will in a couple of pages, we need to make sure that the tclblend.jar thet came with Tcl Blend is in the classpath as well. For example:
setenv CLASSPATH .:/users/johnr/java:/opt/tclBlend1.0/tclblend.jar(As far as the Java class loader is concerned, a .jar or .zip file is the same as a directory containing the the files, and .jar and .zip files are generally used to distribute compiled Java packages.)
On Windows NT, you can use the System control panel to set the CLASSPATH environment variable. On my installation, I set it to:
Once you have done that, change to the tutorial/tcltk98 directory relative to the directory you just set in the classpath and compile the Hello class:
> javac Hello.javaTo check that you can run Java programs, type:
> java tutorial.tcltk98.HelloThis should print "Hello, world!". If not, check that your classpath is set correctly, and that javac and java are in your path. (If your classpath includes the Java core libraries classes.zip, make sure that the version corresponds to the version of javac in your PATH -- a frustrating error you may get if you work with different versions of Java).
More about CLASSPATH
(You may prefer to skip this section and come back to it later.)
The classpath is a little tricky, and for any substantial work in Java we generally prefer not to set the environment variable CLASSPATH. Why? Because we've been bitten often enough by programs getting upset about odd values of CLASSPATH that we prefer to set the CLASSPATH individually for each program or project. Some examples of typical classpath problems:
Here are some ways of avoiding (permanently) setting the CLASSPATH environment variable:
.SUFFIXES: .class .java .java.class: rm -f `basename $< .java`.class CLASSPATH=$(CLASSPATH)$(AUXCLASSPATH) $(JAVAC) $(JFLAGS) $<
javac -classpath .:/users/johnr/java:/opt/jdk1.1.6/lib/classes.zip Hello.java
If you set the CLASSPATH environment variable, the Java tools will know where to find the JDK libraries. If you use the -classpath option, however, you need to explicitly tell the tools where to find their libraries. In JDK versions up to and including JDK1.2beta3, the libraries are in lib/classes.zip relative to the installation directory; in JDK1.2beta4, they are in jre/lib/rt.jar relative to the installation directory.
Having said all that, provided you understand that you'll need to do more work with setting up classpaths if you do more work in Java, all of this tutorial can be run quite easily by setting the CLASSPATH variable by hand, and we'll assume that you can figure out what to do when we say "add so-and-so to your classpath."