What is the proper style for listing imports in Java?

Question

Is it better to list each individual piece of a package you're going to need (see #1) or is it better to just import everything from a package (see #2)?

1

import java.awt.image.ColorModel;
import java.awt.image.ComponentColorModel;
import java.awt.image.ColorConvertOp;

2

import java.awt.*;

Answer 1

It's NOT simply a matter of style; import-on-demand can result in code that ceases to compile as new classes are added to existing packages.

Basic idea (See http://javadude.com/articles/importondemandisevil.html for details.):

import java.awt.*;
import java.util.*;
...
List list;

worked in Java 1.1; as of Java 1.2, the above code will no longer compile.

Import on demand is EVIL because your program can stop compiling when new classes are added to existing packages!

ALWAYS use explicit imports. It's not a matter of style; it's a matter of safety.

This is especially bad if you check in perfectly-compiling code and a year later someone checks it out and tries to compile it with new class libraries.

(Import-on-demand is an example of a really bad programming language feature - no feature should break code when new types are added to a system!)

Answer 2

Use import individually.

It is way lot better for production code to list each and every one of the classes being imported.

While the IDE's do a great job helping you know which classes are being used, it is more readable to know that you're referring to :

java.util.List;

and not

java.awt.List; 

and so on.

Additionally it is recommended that you group them by package starting by the core libraries passing by 3rd party and ending with own project libraries:

 import java.util.List;
 import java.util.ArrayList;
 import java.util.Date;

 import javax.swing.JFrame;
 import javax.swing.JPanel;

 import javax.swing.event.TableModelListener;

 import org.apache.commons.httpclient.cookie.CookiePolicy;
 import org.apache.commons.httpclient.cookie.CookieSpec;

 import your.own.packagename.here.SomeClass;
 import your.own.packagename.here.OtherClass;

Using wildcard is acceptable for small self project/classes. It is faster, but it is not expected to be maintainable. If any other developer is involved, use the first.

Answer 3

If you list them individually it is easier to detect, when reading code with a simple editor (rather than from inside a dev environment), which package objects come from. When reading code from complex projects this can save significant time. Had an example of that earlier today, in fact, when I was studying code from a large open source project without wanting to load everything into eclipse.

Answer 4

The latter is generally considered "bad form". With tool support, there's no excuse for not listing them individually, and it removes any ambiguity.

Mind you, Eclipse by default uses wildcards for static imports, and explicit imports for normal ones. Not sure why it makes that distinction.

edit: the distinction is obvious in hindsight - static imports often refer to static methods, and you can't unambiguously refer to a static method by name (due to overloading). So if it can't be fully unambiguous, you may as well use a wildcard.