USING IMPORT DECLARATIONS

If you've done any amount of Java programming, you've likely used 
import declarations, of the form:


    import java.util.*;

or:

    import java.util.ArrayList;

These are quite simple in a way, but there are a couple of
interesting issues to mention concerning the use of these
declarations.

The first point is that an import declaration makes a type or 
set of types available, but doesn't do any textual inclusion 
of files. By contrast, the C #include directive actually 
substitutes text into the including file. So that:

    #include <stdio.h>

actually results in a header file "stdio.h" being inserted into 
the compilation unit. In Java programming, a corresponding 
declaration:

    import java.util.ArrayList;

simply says that the class type ArrayList can be used in the 
program without full qualification (that is, "ArrayList" instead 
of "java.util.ArrayList").

There's an implicit import declaration:

    import java.lang.*;

assumed at the beginning of a Java compilation unit, just
after any package statement in the unit. A wildcard like "*" says
"make available all public types from the package", in this case,
all types in the package "java.lang". Wildcards are never used to
import subpackages, so an import like:

    import java.lang.*;

doesn't give you access to the classes in java.lang.reflect, a
subpackage of java.lang. You need to say:

    import java.lang.reflect.*;

to access those classes.

What about ambiguities?  What if you import two types with the 
same name from different packages?

    import P1.A;
    import P2.A;

This is invalid usage. However, what if you say instead:

    import P1.*;
    import P2.*;

and both packages P1 and P2 contain an A type?  Well, if you don't
actually use the A in your program, then it's okay. But if you say:

    A a = new A();

you'll get an ambiguity error. In other words, you get an error
if (a) you use a type-import-on-demand declaration (that is, an 
import declaration using a wildcard), (b) two different packages 
have types with the same name, (c) you use that type. There is no
rule that says "the first one wins".

There are a couple of different styles you can use with imports. 
Suppose you need to use ArrayList and Vector from java.util. 
You can say:

    import java.util.*;

or:

    import java.util.ArrayList;
    import java.util.Vector;

These are both "right". The first is terse; you don't have to
enumerate all the types you're using. The second makes clear 
what types you're using in your program, at the expense of some 
verboseness. The second approach also has a subtle advantage in 
that it forces a type to be found in a particular package. Here's 
an example. Suppose you want to use a type A, and you say:

    import P1.*;
    import P2.*;

And you believe that A is found in P1, when it's actually not in P1
but in P2. Explicitly enumerating the types you're using gets
around this problem. If you think A is in P1, and you say:

    import P1.A;

and it's not actually there, you'll get a compile error.

Is there any efficiency issue between these two styles?  Possibly,
but since import declarations don't actually import anything into
your program, any difference is very small. Remember that there's
an implicit "import java.lang.*" at the top of your compilation
units, and java.lang in JDK(tm) 1.2.2 contains 75 classes and
interfaces. An experiment using a contrived example, one with
thousands of class name uses that must be looked up, showed a
negligible change in compilation speed. So compilation 
performance should probably not be considered a factor when 
choosing one format over another.

There's one final angle of interest on import declarations.
Suppose you use an inner class:

    package P;

    public class A {
        public static class B {}
    }

If you want to access A from another compilation unit, you say:

    import P.*;

or:

    import P.A;

But if you'd like to access B without qualification, you need to
say:

    import P.A.*;

or:

    import P.A.B;

The first of these makes available types within the class A found 
in package P. The second makes available just the type B found in
class A in package P.