|
1. | Overview | |
2. | Creating uour own package | |
3. | Example problem - numeric input class | |
3.1. | Requirements | |
3.2. | Analysis | |
3.3. | Design | |
3.4. | Implementation | |
3.5. | Testing | |
4. | Adding a new classpath | |
4.1. | HP-UX UNIX | |
4.2. | Windows NT | |
4.3. | LINUX |
When a largish program is to be written it is often advantageous to divide the program up into chunks (modules) and compile the parts separately. This option is particularly desirable when several programmers are jointly developing a large program. Such chunks of code are called packages in Java. Each package is stored in a directory (folder) which has the same name as the package. Thus a package called LocalPackages will be stored in a directory called LocalPackages.
We have already seen how we can import Java's standard API packages, such as the java.io package, into a program and then use the classes defined in this package. We can also write our own user-defined packages containing implementations of our own classes.
Thus a package is a collection of classes grouped together and stored in a directory in such a way that they can be used by any applications program that we might wish to create.
We will create a package called LocalPackages which contains a single class PackageExample. We will first create a directory LocalJavaPackages in which to place all our packages. We will then create the first class for our LocalPackages package, this is given in Table 1. Note the keyword package which tells the compiler that this class will belong to a package (LocalPackages in tghis case).
// PACKAGE EXAMPLE // Frans Coenen // Wednesday 21 July 1999 // The University of Liverpool, UK package LocalPackages; public class PackageExample { public void doit() { System.out.println("Hooray I have successfully written a package!"); } } |
Table 1: Source code for class to be include in LocalPackages package
If we compile the above using the -d option we can tell the compiler where to place the resulting class:
javac -d . PackageExample.java
Provided that the PackageExample.java source file is contained in our LocalPackages directory this will cause a directory LocalPackages to be created in which we will find the class file PackageExample.java.
To use the classes in a package we must include an import statement in our source code of the form:
import LocalPackages.PackageExample;
However, how does the Java compiler know where to look for the classes contained in the LocalPackages.PackageExample package? The answer is that is has no idea, therefore we must tell it.
We can do this by including the pathname in our compile and execute commands. For example given the application presented in Table 2 we would compile this as follows:
javac -classpath ~frans/LocalJavaPackages/:. PackageExampleApp.java
// PACKAGE EXAMPLE APPLICATION // Frans Coenen // Wednesday 21 July 1999 // The University of Liverpool, UK import LocalPackages.PackageExample; class PackageExampleApp { public static void main(String[] arg) { // create instance of class Package Example PackageExample newObj = new PackageExample(); // Call extended bigest newObj.doit(); } } |
Table 2: Source code for application programme
To run the programme we would type:
java -classpath ~/LocalJavaPackages/:. PackageExampleApp
To produce:
Hooray I have successfully written a package!
Note that it may be convenient to write two "shell" scripts to facilitate the above compilation and execution.
WARNING: THIS WAS WRITTEN IN JUNE 1999 AND MANY NO LONGER REFLECT CURRENT SYSTEMS>
An alternative (more sophisticated way) of telling Java wherte to finf packages is by assigning an appropriate value to a kind of data item known as an environmental variable. The particular environmental variable that we are interested in, in the context of Java packages, is called CLASSPATH. This contains the directory paths indicating the places where the Java compiler should look when searching for packages. This variable will already be set with a number of directory paths indicate where the Java API packages are to be found. Thus when the Java compiler encounters a statement of the form:
import LocalPackages.PackageExample;
It looks for the package LocalPackages.PackageExample according to the paths contained in the CLASSPATH environmental variable in the order that that are presented in this variable. If the Java compiler cannot find an appropriate sub-directory called PackageExamples a compiler error will result.
How you go about changing your CLASSPATH environmental variable
depends on the operating system you are using. Details for HP-UX UNIX, Windows NT
and LINUX are presented in the following sub-sections
4.1. HP-UX UNIX
To adjust the CLASSPATH environmental variable in UNIX we must add some appropriate statements in a file known as the "start up" file or "login script" --- a file that is always invoked when you login. This start up file is an invisible dot (.) file; these are files whose name commences with a dot and which are not normally displayed by a ls command --- hence the tag "invisible" (you can list them by doing a ls .*). The name of this start-up file will depend on what UNIX shell you are using. A selection of common shells with the name of there associated start up (login script) files is given in Table 9. To find out which shell you are in you can type the command echo $SHELL. |
Table 9: Login script dot file names for some common UNIX/LINUX shells |
Within the Department of Computer Science at the University of Liverpool the UNIX system is configured so that the Korn shell is the default shell. The process of changing an evironmental variable varies (slightly) from shell to shell. The following discussion assumes that you are using the Korn shell, in which case you need to edit your .profile. When you have the file in an edit window you will see the contents of your login script. Scroll to the bottom of this script and add the following line:
CLASSPATH=~/LocalJavaPackages export CLASSPATH
After editing the login script you need to logout and log back in again to ensure that the login script is executed correctly. If you now type the UNIX command:
echo $CLASSPATH
You will now see something like:
/HOME/frans/localJavaUtilities
This now means that the Java compiler will now also look in the directory /HOME/frans/localJavaUtilities when looking for packages. (If you wish to include more than one classpath you will have seperate each with a colon.)
Using Windows NT do the following:
setx CLASSPATH %CLASSPATH%;H:\LocalJavaPackages
The CLASSPATH environmental variable will keep this value (even when you log of and log on again) until the next time it is changed (if ever).
Linux systems typically run under the Bash shell and thus you will have to edit the .bashrc file. Using the Bash shell the CLASSPATH environmental variable already contains the paths to the Java API packages. You can "echo" the contents of the CLASSPATH variable to the screen as follows:
echo $CLASSPATH
you will see something like:
.:/usr/local/jdk1.1.7/lib:/usr/local/jdk1.1.7/lib/classes.zip
In this case we have three paths each separated by a ':' character. The first is '.' and means "the current directory". The other two:
/usr/local/jdk1.1.7/lib
and
/usr/local/jdk1.1.7/lib/classes.zip
To adjust the CLASSPATH environmental variable under LINUX (as in UNIX) we must add some appropriate statements in our start-up file, i.e. the .basnrc file when using the Bash shell (see Table 9). Simply add the following to the end of the login script.
CLASSPATH=.:~/LocalJavaPackages:$CLASSPATH export CLASSPATH
As with UNIX, after editing the login script, you need to logout and log back in again to ensure that the login script is executed correctly. If you again "echo" the path you will now see something like:
/HOME/frans/localJavaUtilities:.:/usr/local/jdk1.1.7/lib: /usr/local/jdk1.1.7/lib/classes.zip
Created and maintained by Frans Coenen. Last updated 04 September 2002