JavaRanch Home    
 
This page:         last edited 26 February 2012         What's Changed?         Edit

Wild Card Vs Specific Imports   

What are the implications of using wildcard vs. specific imports?

That is, which style is better:


import java.util.*;

or


import java.util.List;
import java.util.ArrayList;
 ...

Performance

Imports are processed at compile time. The produced byte code doesn't contain any imports any more, but only fully qualified class names. That is, regardless of what style of import you use, the same byte code is produced.

Consequently, the style of import doesn't have any impact on runtime performance or memory usage. It does have a slight impact on compile performance - wildcard imports are a little bit slower, but generally you can safely ignore that.

Readability

Some people argue that specific imports improve the readability of code because they make it easier to see where a class is coming from.

Others find that wildcard imports reduce the "noise" produced by a lot of imports and therefore improve the overall readability. (Though you could argue that a large number of imports is a Wiki:CodeSmell .)

Mostly, this is a matter of taste though. It loses even more relevance with modern IDEs which automatically organize imports, allow hiding them from the developer (i.e. via "code folding") and give him easier access to class information "at a finger tip" than the import statements themselves.

Ambiguities

Wildcard imports have one problem though: they can lead to ambiguities when classes with the same name exist in two packages you import via wildcard.

Imagine the following two imports:


import foo.*;
import bar.*;

Now you want to use the class foo.Node but there is also a class bar.Node. Now you need to use non-wildcard imports to resolve the ambiguity that would happen otherwise.

What if there isn't a class bar.Node - isn't all well, then?

For the moment, yes. But later it could get even worse. Imagine that someone introduces a Node class in the bar package later. Suddenly, your class doesn't compile anymore! And it might well be that the developer who now has to fix this problem isn't that familiar with the code, He might have a hard time finding out what happened and how to fix the problem.


Related Discussions:

JavaRanchContact us — Copyright © 1998-2014 Paul Wheaton