This week's book giveaway is in the Jython/Python forum.
We're giving away four copies of Hands On Software Engineering with Python and have Brian Allbey on-line!
See this thread for details.
Win a copy of Hands On Software Engineering with Python this week in the Jython/Python forum!
    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
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Liutauras Vilda
  • Tim Cooke
  • Devaka Cooray
  • Paul Clapham
Saloon Keepers:
  • Tim Moores
  • Frits Walraven
  • Ron McLeod
  • Ganesh Patekar
  • salvin francis
  • Tim Holloway
  • Carey Brown
  • Stephan van Hulst
  • 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:


    If we don't do the shopping, we won't have anything for dinner. And I've invited this tiny ad:
    RavenDB is an Open Source NoSQL Database that’s fully transactional (ACID) across your database
      Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!