There is not a performance or overhead cost to doing import .* vs importing specific types. However, I consider it to be a best practice to never use import .* My primary reason for this is I just like to keep things straightward, clean and with as little ambiguity as possible, and I think with a .* import you lose that.
Does using * in an import statement affect performance?
This question has come up a surprising number of times in various forums. The question relates to the
import directive, as in
The short answer is: no, there is no affect on runtime performance.
import directive is a compiler directive. The Java source to bytecode compiler reads the Java source file (i.e. a something.java file) and converts that source to one or more bytecode files (.class files).
Most Java source code in the Java source file is converted into Java bytecodes of one sort or another. But the
import directive is not. The
import directive specifically tells the compiler to do something. The
import directive tells the compiler that when it comes across a class or interface name in the source file, e.g.
HashMap, then if it cannot find the class file for that name, it should use the import statement to help it look it up. This way, you don’t have to always use fully qualified class names, e.g.
import directives themselves do not get put into the compiled bytecode files. They are no longer of any use, as the compiler compiles the fully qualified name into the .class file.
For example, suppose the source file contains
import java.util.*; // ... HashMap map; ...
Then the compiler gets to the
HashMap map variable declaration, tries to find a class called HashMap in the default package (i.e. no package name), fails, and uses the import statement to see if there is a
java.util.HashMap class. This is found, and a reference to
java.util.HashMap is inserted into the .class file. After compilation is completed, there is no use for the
import directive, so it is not present at all in the compiled bytecode. Consequently, the
import directive cannot affect runtime code execution in any way.
However, it is worth noting that the directive does affect compilation time. Since the directive tells the compiler how to do a second lookup to find classes, obviously this means that more time is spent looking up class and interface names compared to if one lookup sufficed.
In fact, there are two forms of the
import directive: with and without the wildcard ‘*’, e.g.
import java.util.*; import java.util.HashMap;
Without the wildcard, the directive tells the compiler to look for one specific file in the classpath. With the wildcard, the directive is telling the compiler to look for the named package, and to search in that package for possible matches everytime any name needs to be matched. This latter version is probably going to be more costly (i.e. take longer) for the compiler than the former.
Also, depending on which compiler you use, and which settings, the compiler may re-compile all of the classes in the wildcard package, which could really make things take longer.
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