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