Using wildcards in imports can cause your code to fail to compile when
you upgrade the JDK or other libraries, if the upgrades include new
classes that conflict with existing class.  Whether or not this small
risk is a big deal to you is another story.

Modern IDEs also make it easy to manage imports in either style.

HTH,
Ray

[...]

Personally, I prefer wildcards, because it looks better without code
folding (I dislike lots of what I see as non-code & non-comment). Also (as
already stated), IDE's can easily help in identifying the exact class.

On the other hand: if your code will be viewed with a web view of a SVN/CVS
repository, then explicit listings are better as there is no help in
identifying the fully qualified class name.

import java.util.*;
import java.awt.*;

class Foo {
    private List X = null; // this does not compile
}

Need i say more? ;)

The more I think about it, the less value I see in explicitly importing
classes.

If I see an 'import java.net.*' at the start of a file, then I know "OK, we're
doing networking here", similarly for java.awt, etc.  If I see a long list of
imports then there's no way that I'm going to read through it, make a note of
each class used (perhaps write it on a PostIt note), and keep that list in mind
when I'm reading the code.  All I'll do is scan down it, see that it uses a lot
of classes in java.net, and think "OK, we're doing networking here" -- just as
before.

Then when I'm reading the code, if I see a class with a familiar name, then I
/guess/ what it refers to from my background knowledge that we are doing
networking -- I most certainly do not refer to my pile of PostIts to decide
what class was named in the imports section.

Of course that only works for classes that I might be expected to be familiar
with, and that's my real point.  If a class is named in the code that I can't
be expected to recognise from context, then it doesn't make any difference
whether it was imported explicitly or implicitly back at the beginning of the
file, it is still an unknown /at the point where I'm seeing the class name/.
So I now believe that such names should be fully-qualified at the point of use,
rather than relying on the obfuscating effect of import statements at all.

Put it this way, if a class is part of some context (such as network
programming) that the reader can be expected to be familiar with, then the
explicit import gains nothing (and perhaps costs more work, depending on
which IDE, if any, is used).  If, on the other hand, the class is unknown or
unexpected in that context (say a java.awt.point2d in the middle of networking
code) then the name should be fully-qualified at the point of use.  Imports (of
either style) are /only/ an abbreviation, and -- like most shortcuts -- they
can reduce code clarity if overused.

BTW, note how this ties in with the fairly well-regarded credo that
cross-package references should normally be to interfaces rather than classes.
The names of concrete classes should (mostly) be confined to their own package.
If such design guidelines are followed, then the type names used in the program
code will (mostly) be names of interfaces, and -- they being generic and few --
can be expected to be familiar.  Hence it is (by my reasoning) preferable to
import them using wildcards.  Such names of concrete classes as do occur will
either be (rare) references to foreign classes, or (common) references to
classes in the same package.  The latter case needs no import statement at all,
the former -- /because/ it is rare -- can, and (IMO) should, be handled by
using fully-qualified names at the point of use.

   -- chris

I can think of one reason you want to explicitly list the class name
rather than use a wildcard, that is when there are two packages that
contain the same class.

There are actually three options:

1) Always use wildcards
2) Always use explicit names
3) Use wildcards unless you need explicit names

Option 1 is easier for the programmer creating some code. Option 2 helps
to avoid problems when two packages have the same class name but is more
work for the programmer. Option 3 works. I'd go with option 3. Actually,
most people go with option 1 until they are forced to option 3; many never
need option 3.

I'll go with my original plan and insist on explicitly listing classes.
 I was looking for a compelling reason to go against my view on this,
but didn't really get one IMO.

Thanks for all the responses.