What is the proper style for listing imports in Java?_问答_开发者

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.Com开发者_运维百科ponentColorModel;
import java.awt.image.ColorConvertOp;

2

import java.awt.*;

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!)

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.

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.

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.

I know the question was not about performance but, the cost of import statements question of the month on javaperformancetuning.com perfectly summarize why you should avoid to use wildcards:

(...) Finally, many people find that using imports with wildcards makes the source much less readable, since the reader also needs to figure out which package a particular class comes from, rather than just looking it up in the import statement.

So the full answer is

There is no runtime cost from using an import statement

The compilation process can take a little more time with an import statement

The compilation process can take even more time with a wildcard import statement

For improved readability, wildcard import statements are bad practice for anything but throwaway classes

The compilation overhead of non-wildcard import statements are minor, but they give readability benefits so best practice is to use them

It is a bad practice to use wilcard import statements, they make the code less readable, just don't do it. The only exception to this rule are static import, for example import static org.junit.Assert.*;. No, I don't want to import each assertXXX individually and I don't find that this harms code readability.

There is no one right answer here.

The People Who Brought You Eclipse voted for individual imports, since Source/Organize Imports will convert the * form to the specific form.

If you use an ide like visual studio it typically takes care of this issue for you, so you don't even need to bother thinking about it.

Most IDEs that I am aware of choose option 1 above. This is consistent with some code analysis tools that I used in the past (like checkstyle), as they consider it bad practice to use the * notation.

The option 1 you listed is preferable but if there are more classes you are importing from say java.awt.image, then its preferable to just have one import java.awt.image.* Most IDE's let you specify the exact count of the number of imports to be used. For eg in IDEA, we can use File->Settings->Code Style->imports In the General tab there is a field Class count to use import with * and default value is 5.

whatever the default of your team's IDE is. that way you can just do an autoformat of your file before committing it.

Import individually, it saves the compiler from having to look through each package for each class and therefore makes things run quicker.