• Post Reply Bookmark Topic Watch Topic
  • New Topic

Why not just import everything?  RSS feed

 
Ahmad Auada
Ranch Hand
Posts: 56
Android Eclipse IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 56536
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 7973
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 115
11
Clojure IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 7973
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:
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
Ranch Hand
Posts: 115
11
Clojure IntelliJ IDE Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 7973
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 115
11
Clojure IntelliJ IDE Java
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 1445
30
C++ Java Netbeans IDE Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Saloon Keeper
Posts: 7973
143
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see you guys' points. Stuborn as I am, I've set my NetBeans to use star import always
 
Maxim Karvonen
Ranch Hand
Posts: 121
12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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:

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

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.
 
Consider Paul's rocket mass heater.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!