This question already has an answer here:
-
Why is using a wild card with a Java import statement bad?
13 answers
In Java we can either import single classes as well as the whole set of classes (a package).
As an example
import java.util.*
includes
import java.util.ArrayList;
import java.util.Date;
import java.util.Enumeration;
import java.util.HashSet;
import java.util.Hashtable;
import java.util.List;
import java.util.Iterator;
import java.util.Map;
Other than the length of the code, are there any specific advantages of using the each approach in any manner? Memory allocation? Performance?
There is no performance or memory allocation advantage to either -- they both will compile to the same bytecode.
The import
statement is to tell the compiler where to find the classes that the source code is referring to.
However, there is an advantage to importing only by classes. If there is a class with the exact same name in two packages, there is going to be a conflict as to which class is being referred to.
One such example is the java.awt.List
class and the java.util.List
class.
Let's say that we want to use a java.awt.Panel
and a java.util.List
. If the source imports the packages as follows:
import java.awt.*;
import java.util.*;
Then, referring to the List
class is going to be ambigious:
List list; // Which "List" is this from? java.util? java.awt?
However, if one imports explicitly, then the result will be:
import java.awt.Panel;
import java.util.List;
List list; // No ambiguity here -- it refers to java.util.List.
The imports you choose to use only make a compile-time difference when resolving class names.
So the only advantages/disadvantages apply to readability.
Only importing the minimum you require seems better because someone can look at what you actually are using. That said, the IDE probably handles this and it's a moot point.
There is no difference at all in memory allocation or performance for your application; import statements do not have any impact at runtime on your program at all. They are just directives to tell the compiler where (in which packages) to find classes.
However, it is best to avoid the wildcard syntax and always use specific imports. Doing this will avoid a problem with regard to compatibility with future versions of libraries with your program.
Suppose you are using version 1.0 of some library in your program, and you do import somelibrary.*;
. Suppose your program has a class named X
. Now, version 1.1 of the library comes out and you want to use it. Suppose that by chance there is a new class named X
in version 1.1 of the library.
If you used the wildcard syntax, you are suddenly also importing X
from the library. The compiler will then give you an error, because there's already a class X
in your program, and the compiler can't distinguish between your X
and X
from the library.
If you only import the classes that you actually need from the library, then you don't get this problem, because you won't automatically import X
from version 1.1 of the library.
The advantage of importing using a '*' is that it is fewer lines of code, and less typing. This is more important if you do your coding with a "dumb" text editor rather than an IDE than can use ellipses to hide imports and can add imports semi-automatically.
The disadvantages of importing using '*' are:
- You get imported class name collisions occasionally; e.g. when some class name is used for classes in different packages and you import both of them.
- You cannot see a classes explicit dependencies by looking at the imports. But this is less important if your IDE can show you the dependencies some other way.
Performing an explicit import is safer at compile time, since there's no possibility of a class conflict. e.g.
import java.sql.*;
import java.util.*;
causes a problem if you're trying to use a Date class (i.e. from which package ?).
But other than that, there's no performance or memory aspect. It's purely a compile-time issue.
Any decent IDE will put in the import statements for you and lots more besides. Get a better IDE if this is an issue for you.
IntelliJ does it; so does Eclipse. I don't use NetBeans myself, but I'd bet that it does.