Bookmark Topic Watch Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Devaka Cooray
  • Knute Snortum
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar
  • Tim Holloway
  • salvin francis
  • Mark post as helpful
  • send pies
  • Report post to moderator
What are the implications of using wildcard vs. specific imports?

That is, which style is better:



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.


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.


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:

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:


    With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
      Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!