Packaging in Java

Packaging in Java
An Introduction

Prof. David Bernstein
James Madison University

Computer Science Department

bernstdh@jmu.edu

Packaging

Identifying/Creating Packages

Components with a common purpose:
- The package indicates the types are related
Components that participate in the same use cases:
- The package helps identify the components that provide the necessary functionality
Components that are strongly associated:
- The package allows access across components

Namespaces in Java

Packages Define a Namespace:
- Two packages can contain components with the same name
- Package names can be prepended to class names (e.g., plant.Leaf and hierarchy.Leaf) to create a unique, fully-qualified name
The Namespace Appears Hierarchical but Isn't:
- A package can appear to contain another package (e.g., java.awt appears to contain java.awt.event) but it doesn't

Namespaces in Java (cont.)

Ensuring Uniqueness:
- Use a package name that uniquely identifies the programmer or organization
A Common Convention:
- Use a a "flipped" domain (e.g., edu.jmu.cs.package)
A Detail:
- Java naming conventions still apply so inappropriate elements should be preceded by an underscore (e.g., com._static.package)

Some Java Packages

Using Classes in Packages

Classes in java.lang:
- Nothing needs to be done to use classes in java.lang (e.g., the String class)
Classes in Other Packages:
- Use the fully-qualified name (e.g., java.util.ArrayList)

Using Classes in Packages (cont.)

An Observation:
- Using the fully-qualified name can be very inconvenient (and verbose)
A Remedy:
- Use import statements to tell the compiler/interpreter how to try and resolve unidentified symbols and then use the unqualified name of the class
- A Specific Class: import package.class;
- All Classes: import package.*;
Disambiguating:
- Sometimes you must use the fully-qualified name (e.g., to use both java.awt.List and java.util.List in the same class

Packages and the File System

The Normal Situation:
- Each package corresponds to a directory and the apparent hierarchy is realized as an actual hierarchy (e.g., the package statistics.parametric is in the directory parametric inside of the directory statistics
An Important Point:
- Packages map to a part of the file system (i.e., a package is defined relative to some top-level directory)
Specifying The Top Level:
- When compiling/executing from the command shell: Done using the environment space (i.e., CLASSPATH) or with a compiler/interpreter switch (i.e., -cp or -classpath)
- When compiling/executing from an IDE: Done by adding the packages to the project

Creating Packages

Create the Directory Structure:
- The directory structure (under the top-level directory) should match the package structure
Include the package Statement in each Class:
- package package;

A Convenience

Using static Members:
- The fully-qualified name is package.Class.member
Using static Members from Imported Packages:
- You can omit the package name and refer to them as Class.member
Static Imports:
- If you use import static you can access static members without including the package name or the class name (e.g., abs() rather than Math.abs())

Visibility Revisited

Visibilities You Are Familiar With:

Block	Entity is accessible within a block of code
Subprogram	Entity is accessible within a subprogram
Class/Private	Entity is accessible by all entities within a class
Generalized/Protected	Entity is accessible in its class and all extensions
Complete/Public	Entity is accessible everywhere

Another Kind of Visibility:

Group Entity is accessible to all members of a pre-defined group (e.g., package visibility in Java, COMMON blocks in FORTRAN)

Visibility Revisited (cont.)

Package Visibility in Java:
- Attributes are visible to all classes in the same package
- Implemented by not specifying an explicit visibility
Protected Visibility in Java Revisited:
- Attributes are actually visible to subclasses and other classes in the same package
Package Visibility in UML
- Denoted using a ~

Deployment

An Observation:
- Directory trees are a good way to organize packages
- It is often inconvenient to move directory trees around
One Solution:
- Java Archives (.jar Files)

Java Archives

Simple Archives:
- Multiple classes/packages combined in a single file
- Created using the jar tool
- Can be included in the CLASSPATH
Executable Archives:
- Can be made to appear "executable" (though they are actually interpreted by java or javaw)

Java Archives (cont.)

Resources:
- One sometimes wants to include files other than .class files in a .jar file (e.g., images, configuration files, input files)
- Such files are often called resources
"Loading" Resources:
- File objects normally refer to files in the file system
- To refer to a resource in a .jar file you should use a URI object
- Constructing the URI is a multi-step process that uses the getResource() method in the Class class

Creating Java Archives