Why not just import everything?

[Ahmad Auada]

If my program is going to input and output some data, then why should I use
import java.io*;

I could just import everything, right?
import java.*;

[Campbell Ritchie]

Ahmad Auada wrote:. . .
import java.*;

That will import every class in the java package. And the number of classes in the java package is 0. That is not how import works, and you cannot import contents of packages by giving the names of their surrounding packages. It was designed that way, to deal with the situation where there are two classes in different packages with the same name.

[Stephan van Hulst]

Star import is not recursive. While package names imply that there's a hierarchy, actually there isn't. The java package is completely unrelated to the java.io package.

[Jason Bullers]

And you probably shouldn't use import java.io.* either. When you throw open the flood gates with a wild card import, you run the risk of naming collisions as Campbell mentioned. Granted, there may be some cases where it's handy, but you should think about how much you really need from that package.

As an example, here's one I've run into before. I'm doing graphical stuff, so I need classes under the java.awt package (such as Color, etc.). I could just import java.awt.*, but now what happens if I'm also using List collections in my code? Naming collision! There's a java.util.List (the collection) and a java.awt.List (the old awt List component). If I use the wildcard import for the awt stuff, now everywhere I use the List collection type, I have to explicitly write java.util.List to get around the naming collision.

[Stephan van Hulst]

Personally I've never really understood the reason star imports are discouraged so much. Any ambiguity is immediately picked up by the compiler, and any IDE can tell you the fully qualified type of a variable if you select it. Collisions can easily be resolved:

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

import java.util.List; // explicit import for list, no collision with java.awt.List!

Have people actually lost significant time because they had to look through the packages to find the right class? I hardly think so. Instead, the long lists of single imports just annoy me.

[Jason Bullers]

Stephan van Hulst wrote:Have people actually lost significant time because they had to look through the packages to find the right class? I hardly think so. Instead, the long lists of single imports just annoy me.

I could argue the exact opposite: my IDE does a great job of importing automatically when I auto complete. Have people actually lost significant time adding and managing imports? I wouldn't think so since IDEs are very good at making that easy for me.

What I do get from a long list of single imports is a way of seeing what my dependencies are at a glance. If everything is wild card imports, I don't learn anything by looking at them. Does your class really depend on all of java.awt and all of java.util? Doubtful, but I'll never know which specific classes it depends on without reading all your code. To me imports are as much about documentation as they are about being able to use a class name without fully qualifying it.

[Stephan van Hulst]

Jason Bullers wrote:but I'll never know which specific classes it depends on without reading all your code.

I think I have yet to encounter the scenario where I need to know all types my type depends on, without needing to know where or how they are used

[Jason Bullers]

Stephan van Hulst wrote:I think I have yet to encounter the scenario where I need to know all types my type depends on, without needing to know where or how they are used

That's fair. In my experience it's more the length of that long line of imports that's been meaningful at first glance. Separation of concerns in a lot of the code I work with is sometimes questionable, and it's nice to be able to look at those imports at the top and wonder: "Wow, this class sure does pull in a lot from all over the system. Is it doing too much?"

EDIT: This is especially true when those imports show an obvious violation of conceptual separation between components.

[Stevens Miller]

Jason Bullers wrote:my IDE does a great job of importing automatically when I auto complete.

NetBeans (the IDE I mostly use) has good support for this. It never uses wildcards, afaik. Yes, the list of imports can get a bit long (agreed that this can flag code in need of division/simplification), but I don't really notice them. They're kind of like the advertisements that adorn the Web sites I visit: you learn not to see them.

[Stephan van Hulst]

I see you guys' points. Stuborn as I am, I've set my NetBeans to use star import always

[Maxim Karvonen]

Stephan van Hulst wrote:Personally I've never really understood the reason star imports are discouraged so much.

Upgrading.
Assume you are using version 1.1.2 of my library. You have imports like:

import java.io.*;
import ru.maxkar.some.library.*;

public class YourClass { ... }

It compiles and works well. Over two months I improve my library. I only add new methods and classes and do not change any existing behaviour. Those changes are backward-compatible. Then I release a version 1.2. You read release notes for the version 1.2 and see some new method you really need. So you decide to upgrade. You change a library/build specification. Then you compile your project and get a very confusing error stating that usage of "File" is ambigous in YourClass. Turns out that I have added a File into ru.maxkar.some.library package.

Yes, compiler would warn you about ambiguity. But would it be easy for you to resolve? You may forget what was supposed to be used in the file. My File have an API similar to java.io.File API. So YourClass could be compiled with both my File and JDK File. And you'll have to find users of YourClass to figue out which exactly File was passed in a call to

public void yourMethod(File someFile) {
  System.out.println(someFile.length());
}

Of course, you could still read a full change log of my library and figure out the offending class. But what if your are updating many libraries simultaneously?

Creating "File" class was not a best my idea and probably I would not do that. But the similar scenario could arise with other classes and third-party libraries.