Wildcard imports usage in Java and Scala

Question

Recently I have heard statements like "you should never use wildcard imports" too often. So I want to ask community about this. Should wildcard imports really never ever be used in Java production code, no matter what? Are there exceptions to this rule? I interested in your personal experience and opinion. Do you use them in your production code and would you recommend it to others? How do you use them - can you recommend the best way to make it.

It also interesting to look at it from Scala perspective. Is the same applies to Scala? Or wildcard imports in Scala should be only used in presentation slides and SO answers?

If you will look at scalaz page, for example, they recommend usage of wildcard imports like:

import scalaz._
import Scalaz._

I think it also important to consider implicit conversions that are normally imported with wildcards.

You should never listen to advice that starts with "you should never". — musiKk, Mar 15 '11 at 11:39
@musiKk: I trying :) but if you hear it too often, you start yo doubt yourself... — tenshi, Mar 15 '11 at 11:45
@musiKk, You should never listen to advice that starts with "you should never ... too often" ;) — Peter Lawrey, Mar 15 '11 at 11:46
http://stackoverflow.com/questions/147454/why-is-using-a-wild-card-with-a-java-import-statement-bad — Vasil Remeniuk, Mar 15 '11 at 11:53
You should never care about Java imports. They have no value other than preventing name conflict in rare cases. IDE should take care of them. For scala, does it lack such IDE support? — irreputable, Mar 15 '11 at 19:48
@irreputable: Sorry, but I will follow advice in the first comment :) — tenshi, Mar 16 '11 at 08:29

score 19 · Accepted Answer · answered Mar 15 '11 at 12:30

In Scala, wildcard imports are a must, since many libraries expect their implicit conversions to be in scope, but they're not always conveniently named. So,

import collection.JavaConversions._

is a great idea, whereas

import collection.JavaConversions.{asJavaConcurrentMap,enumerationAsScalaIterator,...}

is incredibly awkward. Better yet, in Scala you can put your imports in any scope:

package mypackage {
  class MyClass {
    def myGraphicalWidgetHandler {
      import java.awt._
      ...
    }
    ...
  }
  ...
}

which really helps keep the namespace clutter down throughout the whole file. And you can selectively rename parts of the import that you know will conflict:

import java.awt.{List => AwtList, _}

In contrast, in Java, you're restricted to global scope for imports, and you can't rename them; you also don't have implicit conversions, so it's okay to only pull in those things that you're looking for. On the other hand, you have powerful IDE support that will help find the class that you're looking for and import just it for you. So for Java, there's a reasonable argument to be made that you should let your IDE pull in just what you need rather than you deciding to grab everything. Personally, I still find this too awkward and just use wildcard imports most of the time.

score 13 · Answer 2 · answered Mar 15 '11 at 11:45

Well, by specifiying full classnames you remove ambiguity. So, when you explicitly state which class to import it's a lot easier to understand the intention of the code. Java 1.2 also comes to mind:

import java.util.*;
import java.awt.*;

...
List blah;

This worked fine in Java 1.1. However, in Java 1.2 a List interface was added to java.util, and the code that used to be fine didn't work anymore. Lots of developers cried.

score 8 · Answer 3 · answered Mar 15 '11 at 11:53

In Java, using wildcards for import or not is mostly a question of code maintainability and [un-]willingness to deal with import ambiguities (when two imported packages have members with the same names). On the other hand, from the ideology perspective, it's makes a lot of sense to import the entire pack (say, java.sql._) is you want to have a consistent behavior, and avoid multiple lines of imports from the same package.

The most of it is true to Scala, with the difference that:

If you want to import multiple members from the same class not polluting the code, and, at the same time, avoid possible ambiguities, Scala offers a special syntax for that: import java.io.{File, FileInputStream};
In Scala you can give aliases to the imported members, for dealing with ambiguities: import java.lang.{Double=>JDouble};
As you correctly mentioned, using a wildcard import you add implicits to the context, which may lead to another level of ambiguities (so that's another reason to think twice);

So, all in all, IMO, wildcard import syntax in Scala should be used only in the case, when you're working with a specific library and want it to act consistently (in case of Scalaz, to have all the required members, implicit conversion, etc. in place).

I like your emphasis on importing implicits, especially defined in package objects. — Peter Schmitz, Mar 15 '11 at 13:09

Chris · Answer 4 · 2011-03-15T11:48:12.260

2

For the Java side: There is absolutely nothing wrong with using wildcard imports! There is no performance lack at runtime because only the Classes which are actually be used are loaded.

The import mechanism of java takes place at compile time. The only thing it is used for is if you use the Class Date for example in your code ant there is no class Date in the same package the import mechanism will be used to find the class Data in one of the import statements.

So all it does is "finding out what class you are referencing to". Nothing what could change your runtime performance.

edited Mar 15 '11 at 11:48

answered Mar 15 '11 at 11:42

Chris

7,675
8
51
101

As Andiaz said there could only be a problem if two classes of the same simple Name are existing in two different imported packages. – Chris Mar 15 '11 at 11:50
1

True, performance-wise there's no difference, but if one day your build process complains about unknown class Foo, and you have wildcard imports, good luck determining which package it's suddenly missing from. Been there, done that. – Imre Oct 12 '12 at 12:41

Wildcard imports usage in Java and Scala

4 Answers4

Linked