Welcome to the wonderful world of classpaths, packages and directories, which drove me away from Java the first time I tried to use it (in 1997 or so). Don't feel bad - it's genuinely wacky at first.

Long post follows. Or skip it and read the Sun tutorial. Or read it and read the Sun tutorial on packages.

Java breaks up classes into "packages" - groups of related classes. Each package has a dotted name sort of like object references, such as

package com.lewscanon.whoneedsstruts.dispatcher;

Notice that it looks an awful lot like a backwards URL; that's because that's what it is. This package belongs to the domain "lewscanon.com" at least fictionally, and within that domain it has a group of things named "whoneedsstruts" and another group of things called "whoneedsstruts.dispatcher".

Notice that the second one looks like it sort of belongs to the first. It does not. Despite the common element "com.lewscanon.whoneedsstruts" between them, the two packages are separate.

Every class that belongs to a package has a full name, the combination of the package and the class name, such as

com.lewscanon.whoneedsstruts.dispatcher.Dispatcher

This is a class 'Dispatcher' that belongs to the package 'com.lewscanon.whoneedsstruts.dispatcher'.

In a typical file system, each class is represented by a .class file, which perforce resides in a subdirectory of the file system. So somewhere on my hard drive I have this file 'Dispatcher.class' that has the bytecode for the 'Dispatcher' class. But in what subdirectory? Here the joy begins.

To help things along, Java loads classes from subdirectories that match package name parts exactly, with each name part corresponding to another subdirectory level. So my package

com.lewscanon.whoneedsstruts.dispatcher

has a subdirectory with the relative path

com/lewscanon/whoneedsstruts/dispatcher/

in which we find a file 'Dispatcher.class'.

Notice that I did not put a leading '/' in that path - it is relative to some parent directory. Let's say that I put all my Java applications inside the directory

/opt/apps/

Then the full pathname to the class file is

/opt/apps/com/lewscanon/whoneedsstruts/dispatcher/Dispatcher.class

See how the directory parts match the package parts?

But how does Java know to start at /opt/apps? By the classpath. You found out that the CLASSPATH environment variable can help, but that is a global and somewhat inflexible solution. More useful is a parameter '-cp' ('-classpath') to the 'java' command:

java -cp /opt/apps com.lewscanon.whoneedsstruts.dispatcher.Dispatcher

Notice that I told 'java' a fully-qualified class name, with dots not slashes. This is a class name, not a file name, so it is "package.Class", not "path/Class.class". The '-cp' option did use slashes, because its argument is a path.

A path can hold many directories, separated by ':' in UNIX, ';' in Windows.

java -cp /opt/apps:/var/moreapps com.lewscanon.whoneedsstruts.dispatcher.Dispatcher

(Ignore line wrapping caused by the newsgroup)

If the relative path cannot be found in /opt/apps/, 'java' will look in '/var/moreapps' to find the class file.

Your error message complained because you gave a classpath all the way down to the bottom directory, sort of like trying to say

java -cp /opt/apps/com/lewscanon/whoneedsstruts/dispatcher ...

The problem there is that the package is

com.lewscanon.whoneedsstruts.dispatcher

which would be several directories further down than exist. Your situation is similar. You have a class 'ptolemy.plot.Plot' which has to be in the directory

ptolemy/plot/

below a part of your classpath. If your classpath goes all the way down to c:/ptolemy/plot/, then the class would need to be in

c:/ptolemy/plot/ptolemy/plot/Plot.class

Instead, try

java -cp c:/ ptolemy.plot.Plot

Read Sun's tutorial.

-- Lew