Espresso: A Concentrated Introduction to Java

Java Packages

Summary: This document gives a quick overview of the purpose of Java packages and how to work with them in the MathLAN.

Prerequisites: None

Contents:

• Introduction
• Package Names
• Indicating The Package
• Directories and Package Names
• The Class Path

Introduction

Because Java was designed for programming in the large, the designers of Java worried about name clashes. (E.g., If I design a class called Foo and you design a class called Foo, how do we distinguish them, particularly in a program that uses both?) As a solution to this problem, they created packages. In essence, each package creates its own name space. (Alternatively, packages give you longer names for things.)

You use packages almost as soon as you start using java. For example, when you use the java.io.PrintWriter class, you're using a class in package java.io.

Although most programmmers have no trouble using classes in already-created packages, many programmmers are not sure how to manage their own packages. This document attempts to explain how to use packages in the MathLAN (and, I expect, on most *nix systems).

Package Names

At first glance, packages are easy. You choose a name for your package and you put the keyword package and the name of the package at the start of your source file. (You may have seen these details in the some examples.)

However, choosing the name for a package can be hard. Different developers sometimes seem to have different models for naming their packages. The standard suggests that you use a fully qualified name that is, essentially, the reverse of the domain you might use. For example, my code should probably be in a package that starts with edu.grinnell.cs.rebelsky.

For my classes , I would prefer that you use group-or-individual-name.assignment. For example, Sam Smith with account smithsa would use package smithsa.hw2 for homework two.

Indicating The Package

You indicate the package to which a particular class belongs by beginning its file with a package directive. This directive takes the form

package nameofpackage;

Directories and Package Names

The next thing you need to realize is that package names must correspond to directory names. Hence, if you have a package named project (not a good name for a package), it must be in a directory named project. If you have a package named smithsa.hw2, it must be in a a directory named hw2, which is in a directory named smithsa.

The Class Path

But where does smithsa belong, or more precisely, where does Java look for your packages? On most Unix systems, it looks at an environment variable called CLASSPATH. This variable contains a list of directories separated by colons.

In the MathLAN, I recommend that you add something like the following to the end of your .bashrc to set the CLASSPATH

export CLASSPATH="$CLASSPATH:/home/yourusername/directoryforthisclass:.:/home/rebelsky/Web/Courses/CSC152/2005S/Examples"

This instruction tells Java to first look where it used to look, then to look in the directory for this class, then to look in the current directory (indicated by a dot), and finally to look in the examples directory for my class.

History

Tuesday, 31 August 2004 [Samuel A. Rebelsky]

• Created as documention for CSC223 2004F.

Sunday, 30 January 2005 [Samuel A. Rebelsky]

• Rewritten significantly for Espresso.

Tuesday, 30 August 2005 [Samuel A. Rebelsky]

• Minor rewrites.