Java specifies a convention for generating globally unique names for classes/interfaces. The convention is that a package name starts with the components of the author's Internet address (in reverse order). Examples are:

organization          domain name  an example of a class/interface name
Sun Microsystems      sun.com      com.sun.xxx.yyyyy
IBM                   ibm.com      com.ibm.wwww.vvv.uuuuu
University of Durham  dur.ac.uk    uk.ac.dur.aaaaa.bbb.ccc.dddd

If the University of Durham wanted to establish a convention for the uniqueness of the names of classes/interfaces, it could utilise a person's username. So I might prefer to put the Date class mentioned earlier into the package:

package uk.ac.dur.dcl0bjc.utils.dateutils;

And if I wanted this package to be accessible from the WWW (see below), then it would be sensible to put the files of this package into the directory:

/users/dcl0bjc/public_html/uk/ac/dur/dcl0bjc/utils/dateutils

Having done this, if you needed to use this package in a Java application, you would need something like:

import uk.ac.dur.dcl0bjc.utils.dateutils.Date;

and you would need to set the CLASSPATH:

setenv CLASSPATH .:/users/dcl0bjc/public_html

in order for the Java compiler/interpreter to find the .class files.

The reason for putting these .class files in a directory that is below a user's public_html directory is that they can then be accessed by a Java applet running on a WWW browser elsewhere in the world. You can use the CODEBASE attribute of an APPLET/OBJECT/EMBED tag if you want to indicate that an applet's .class files are all stored in a particular place, e.g.:

CODEBASE=http://www.dur.ac.uk/barry,cornelius/