The name used with an import statement must be the canonical name of a package (for import on demand) or
type (for single type import). As discussed in "Naming Classes" on page 411, the canonical name and fully
qualified name can differ only for nested types. Note that generic types are imported using their raw type
namethat name can then be used in a parameterized type without further qualification.
Code in a package imports the rest of its own package implicitly, so everything defined in a package is
available to all types in the same package. The package java.lang is implicitly imported in all code.
The import mechanism is passive in that it does not cause information about the named packages and types to
be read in at compile timeunless a type is used. The import statement simply tells the compiler how it can
determine the fully qualified name for a type that is used in your program if it can't find that type defined
locally. For example, as described on page 181, if your class declares a reference of type Attributed the
compiler will search for the type in the following order:
- The current type including inherited types.
- A nested type of the current type.
- Explicitly named imported types (single type import).
- Other types declared in the same package.
- Implicitly named imported types (import on demand).
If, after that, the type is still not found it is an error. It is also an error if any package named in an import
statement cannot be locatedeven if there is no actual need to obtain a type from that package.
Resolving which type is being referred to requires some work by the compiler, and use of import on demand
may involve more work than resolving a single type import. However, this is rarely significant in the
compilation process. The choice between a single type import and import on demand is usually a matter of
personal preference or local style rules. Naturally, to resolve conflicts or to ensure that a specific type is
resolved correctly you may need to use a single type import.[1]
[1] For example, if you use import on demand for a given package and there is a type in that
package with the same name as a type in the current package, then the current package type
would be found ahead of the imported package. In this case you could use a single type
import for that one type to make it clear that it is the type from the other package that is
required. Alternatively, of course, you could just use the fully qualified name.Type imports can also be used with nested class names. For example, in Chapter 5 we defined the
BankAcount class and its nested Permissions class. If these classes were in the package bank and you
imported bank.BankAccount, you would still need to use BankAccount.Permissions to name the
Permissions class. However, you could instead import bank.BankAccount.Permissions and then
use the simple name Permissions. You don't have to import BankAccount to import the class
BankAccount.Permissions. Importing nested type names in this way should generally be avoided
because it loses the important information that the type is actually a nested type.
Static nested types can be imported using either the type import mechanism or the static import mechanism. If
you insist on importing nested types, then you should use the type import mechanism for consistency.
The package and import mechanisms give programmers control over potentially conflicting names. If a
package used for another purpose, such as linguistics, has a class called Attributed for language
attributes, programmers who want to use both types in the same source file have several options:
Refer to all types by their fully qualified names, such as attr.Attributed and
lingua.Attributed.