SCJP Study Guide:
Declarations, Initialization and Scoping


Printer-friendly version Printer-friendly version | Send this 
article to a friend Mail this to a friend


Previous Next vertical dots separating previous/next from contents/index/pdf Contents
XyzWs SCJP Study Guide: Package

Package


A package is a collection of related types providing access protection and name space management. Note that types refers to classes, interfaces, enums, and annotations. Programs are organized as sets of packages. Package is name space for all the types in it. Each package has its own set of names for types, which helps to prevent name conflicts.

The Java package and import statements work together to scope a package's classes into a new namespace.

Defining packages


To place code into a named package, place a package declaration and a package name at the top of a class source file:

A package represents a group of classes. A package statement should be the first valid statement in the source file. If there is no package statement, the classes in the source file belong to the default unnamed package, or else they belong to the named package. Only one package statement is allowed in a source file. In a source file, there can be only one public class, and the name of the file should match that of the class. An import statement allows you to use a class directly instead of referring to it using its fully qualified name. Import statements must come after any package statement and before the class declarations, as shown below:

They must come right after the package statement, before the class statement.

package com.abc; // package statement 
import java.net.*; // wild card import (imports all classes in the package) 
import java.util.Vector; // class import (only the given class is imported) 

In addition to organizing classes in a clearly defined manner, packages also prevent name collisions. That is, if you use classes from other sources, it is inevitable that eventually duplicate class names will occur. If they are in different packages, however, this is not a problems since their full package names would differ.

The import directive tells the compiler where to look for the class definitions when it comes upon a class that it cannot find in the default java.lang package. So, for example, in the class definition below for Test, the import statements

import com.*;
import com.utils.*;
import java.applet.*; 

public class Test {
...
}

indicate that classes can be found in the com and com.utils packages and also that the Applet class can be found in the java.applet package.

Summary

  • Every class is part of some package.
  • All classes in a file are part of the same package.
  • You can specify the package using a package declaration: package name ; as the first (non-comment) line in the file.
  • Multiple files can specify the same package name.
  • If no package is specified, the classes in the file go into a special unnamed package (the same unnamed package for all files).
  • If package name is specified, the file must be in a subdirectory called name (i.e., the directory name must match the package name).
  • You can access public classes in another (named) package using: package-name.class-name
  • You can access the public fields and methods of such classes using: package-name.class-name.field-or-method-name

    You can avoid having to include the package-name using: import package-name.*; or import package-name.class-name; at the beginning of the file (after the package declaration). The former imports all of the classes in the package, and the second imports just the named class.

    You must still use: class-name to access the classes in the packages, and class-name.field-or-method-name to access the fields and methods of the class; the only thing you can leave off is the package name.


Previous Next vertical dots separating previous/next from contents/index/pdf Contents

  |   |