Win a copy of Practice Tests for OCP Java 17 Certification Exam (1Z0-829) this week in the OCPJP 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Tim Cooke
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Liutauras Vilda
  • Rob Spoor
  • Junilu Lacar
  • paul wheaton
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Scott Selikoff
  • Piet Souris
  • Jj Roberts
  • fred rosenberger
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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:


    pie. tiny ad:
    Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
      Bookmark Topic Watch Topic
    • New Topic