views:

333

answers:

10

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.*;
A: 

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.

bmargulies
actually it's a configurable upper limit, ie use * if more than X from same package.
pstanton
Unless you use more than 10 imports from the same package, case in which Eclipse uses the *-import type (by default anyway)
laura
+2  A: 

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.

skaffman
I think part of the point of static imports is to replace inheriting an interface of constants, and if you had to do one at a time imports it would kind of interfere that part of the purpose, so a wild card has more of a place in that case.
Yishai
Another good use case is `import static org.junit.Assert.*;`. No, I don't want to import each `assertXXX` individually.
Pascal Thivent
Yup, good example.
skaffman
+2  A: 

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.

davek
+22  A: 

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.

OscarRyz
+1 Good examples. I hope it's not inappropriate to ask: Did you mean to start over? http://stackoverflow.com/users/20654/oscar-reyes v http://stackoverflow.com/users/249231/oscar-reyes
trashgod
it looks like he is seeing how much interest (in points) his original profile can gain despite no longer answering questions on it.
Tim Bender
I disagree with organising packages as groups of core, 3rd party and project packages. It is a common practice but I prefer to list all imports alphabetically. I find it's easier to find what I'm looking for.
Dan Dyer
+1, I got bit by the List issue myself.
MAK
I find Alt-Enter and Control-Alt-o (JDeveloper) to be faster than typing `import java.util.*` ...
Dave Jarvis
A: 

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.

Yoni
A: 

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

ridecar2
It's been a while since I studied this, but I don't believe `import` statements have any effect by the time the JVML code is executed. In the JVML all referenced classes have to be mentioned explicitly. The compiler issue may be valid - I'd be curious to see benchmarks.
Dan
Correct - there is no runtime penalty (though it can make the compiler a wee bit slower to use import-on-demand). Imports are only "aliases" that get expanded in the generated .class file. Explicit imports are directly expanded; import-on-demand forces a search on the classpath to find which qualified type name to include in the .class file)
Scott Stanchfield
Thanks for the clarification, I was always just lead to believe that it made something faster.
ridecar2
A: 

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.

Harsha
A: 

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

+26  A: 
Scott Stanchfield
Also, some modern Java IDEs automatically (or by keystroke) add explicit imports.
Dave Jarvis
A: 

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.

Pascal Thivent