9

Possible Duplicate:
Why is using a wild card with a Java import statement bad?

Right now I'm using a lot of java.util packages:

import java.util.Calendar;
import java.util.logging.ConsoleHandler;
import java.util.logging.Level;
import java.util.logging.LogRecord;
import java.util.logging.Logger;

Would it be more efficient to just do:

import java.util.*;

What are the performance/efficiency costs of this? Does it even matter? Please excuse my ignorance on the subject.

Also, this is just a shot in the dark but is there a way to import packages for a whole project? So that I don't need to re-import them on a per-class basis? This is my first big Java project so I'm still learning the more enterprise side of things.

Community
  • 1
  • 1

5 Answers5

7

It's good practice to import specifics. Eclipse does this for you without any work from you - just use "Organize imports" (press ctrl+shift+o windows or cmd+shift+o mac).

The reason is there's never any confusion over which classes you're loading.

Bohemian
  • 412,405
  • 93
  • 575
  • 722
5

Also, you can't include a whole tree. You can cut down your import list to

import java.util.Calendar;
import java.util.logging.*;

but

import java.util.*;

does not import anything in the java.util.logging package. For the Java compiler, there are no subpackages. Also not for the VM (apart from some classloaders which use the package structure as a file directory structure).

Also, it seems you are mixing the concepts package and class/interface (or type). java.util and java.util.logging are packages, while java.util.Calendar, java.util.logging.Level etc. are classes.

A type (class/interface) is something you can use in your programm, while a package is mainly only a name space in which to put classes and interfaces. (Additionally, it has some consequences on visibility.)

You can import either single types (by specifying their name) or all types directly in a package (by specifying the package and .*). (You can also import all nested types in a type by using a wildcard, or import all static methods/fields of a class with import static <class>.*, just for completeness).

Importing is never recursive, wildcard importing is only for one level. (And you also can't use import java.util.*.* to import the logging classes.)

Paŭlo Ebermann
  • 73,284
  • 20
  • 146
  • 210
2

Importing a wildcard package might slightly slow down compilation, but will have no effect on subsequent performance of the running code.

Importing just the classes you want is preferred, though.

Alnitak
  • 334,560
  • 70
  • 407
  • 495
1

I always prefer to import everything seperate. In my projects it is also a code convention and wildcards in import statements are forbidden.

See answers to this question for good reasons why.

Community
  • 1
  • 1
Fabian Barney
  • 14,219
  • 5
  • 40
  • 60
1

What are the performance/efficiency costs of this?

None. The import + short class name to fully qualified name is resolved at compile time.

Does it even matter?

Sort of. When you import a whole package, you leave yourself open to future compilation errors, because some of the packages you import can grow in future releases, leading to ambiguous imports.

Also, this is just a shot in the dark but is there a way to import packages for a whole project?

No. If you are importing packages other than java.util, java.text over and over again, I would call that a stink of an anti-pattern. Perhaps there are abstractions you are missing in your codebase. Facades, base classes, all reduce direct coupling and dependencies on external packages.

Dilum Ranatunga
  • 13,254
  • 3
  • 41
  • 52