Commenting

Packages

Packages provide a grouping for related Java classes, interfaces, and other reference types. For example, the Java platform provides many helpful utility classes in the java.util package, input/output classes in the java.io package, networking classes in the java.net package, and lightweight GUI components in the javax.swing package. Using packages is a great way to manage both conceptual and physical complexity. In fact, the package structure of large Java projects is dictated by an application s software architectural organization.

In Java For Artists I will show you how to work with packages. A package structure is simply a directory hierarchy. Related class and interface source-code files are placed in related directories. The ability to create your own package structures will prove invaluable as you attempt larger programming projects.

I will use several package naming conventions to organize the code in this book. For starters, I will place short, simple programs in the default package. By this I mean that the classes belonging to short demonstration programs, with the exception of the code presented in chapters 1 and 2, will reside in the default package. Now I know this is cheating because the default package is specified by the absence of a package declaration statement. If you omit a package declaration statement from your programs, they too will reside in the default package. I do this, honestly, because novice students find the concept of packages very confusing at first. Learning how to create and utilize home-grown packages is a source of frustration that can be safely postponed until students master a few basic Java skills.

I use the following package naming convention for the code presented in chapters 1 and 2:

 com.pulpfreepress.jfa.chapter1

An example of this package structure appeared earlier in examples 1.1 and 1.2. For complex projects presented in later chapters I slacked off a bit and shortened the package naming convention to the following:

 com.pulpfreepress.package_name 

Both of these package-naming conventions follow Sun s package-naming recommendations. I recommend that you use the following package naming convention for your projects:

 lastname.firstname.project_name 

So, for example, if you created a project named RobotRat and your name was Rick Miller, the code for your project would reside in the following package structure:

 miller.rick.RobotRat