Using package imports can cause hidden problems. When
you upgrade Java, or some other library, there may be
new classes. The worst case is that you have a class with
the same name as one of these, that has all the methods
you use, and that does almost the same thing or is rarely
used and rarely tested. So your project will compile, but
will break at runtime in rare circumstances. For a large
project, this is not as improbable as you might think. A
more common case is that a new class with the same
name as one you are using is introduced, but you are
using methods it does not have, or it breaks in an
immediate and obvious way at runtime.

You usually don't HAVE to do this.

The only case where importing too much is an error is when two package
imports both cover the same name. The classic example is java.util.* and
java.awt.*, which both have define "List".

However, there are two motivations for keeping imports pruned:

1. Avoiding future ambiguity. Recompiling with a new version of the SDK
could introduce an ambiguity at an inconvenient time.

2. Conveying information to readers of the program. Seeing the actual
imported class list gives an impression of the sort of things the
program does.

Patricia

Thanks everyone,  I also want to know does unused import cause memory
problem, I mean, it will use more memory?

There are a number of reasons and a few silly ones. It will slow down
compilation time asymptotically and it will not affect runtime at all
(classes are fully qualified in the class' bytecode constant_pool).

The more important reasons relate to "encapsulation". First, if I were to
read code that contains wildcard imports, I *must* be able to compile that
code (i.e. know of all its dependencies and importantly, "dependency candidates
that are not dependencies" - see below), otherwise, I have no way to
derive the qualified name of a type.

Here is an example:

import comx.*;
import comy.*;

public class X {
   {
       // what exactly is Type?
       Type t;
   }  

   // This is where it is worse, I cannot
   // determine how to call this method.
   // All I know is it accepts either comx.Type or comy.Type.
   // I cannot after all, derive all types of a given package.
   // My best guess is the same as my worst guess - infinity.
   public void method(Type t) {

   }
}

A final reason is that an introduction of a type into a package can cause
a build failure. This is behaviour that is certainly undesirable. This is
why I need to know build time dependencies and "dependency candidates
that are not dependencies" if wildcard imports are used. Quite
unreasonable given the near infinite possibilities.