Re: Why so many imports instead of java.io.* ?
On 8/14/2012 9:16 AM, Patricia Shanahan wrote:
On 8/14/2012 5:45 AM, Eric Sosman wrote:
On 8/14/2012 8:23 AM, Timothy Madden wrote:
Hello
Is it just me or people tend to enumerate all the needed classes for a
Java source file each in its own import line ?
Why is it better to use:
import java.io.IOException
import java.io.FileNotFoundException
import java.io.FileOutputStream
import ...
instead of just:
import java.io.*
?
Which, by the way, also needs no maintenance in case a new class or
exception is needed in the file at a later time.
On the other hand, it *will* need maintenance if the next
Java release adds a java.io.Wotsit class, and your file already
has its own Wotsit. Import them one by one and the new Wotsit
won't clash with yours; import them en masse and it will.
The rest of the answer, I think, is that Somebody Somewhere
decided that it was "better style" to import individually than
by wildcard, and SS' opinion got codified into the out-of-the-box
settings for tools like Eclipse and NetBeans. Bowing to SS' ideas,
these tools complain about wildcard imports, while at the same time
making it easy to generate the individual imports. Most people
don't tinker much with the out-of-the-box settings, so the code they
create with these IDE's follow that style.
I don't think the out-of-box settings in e.g. Eclipse should drive
actual programming style. A programmer who prefers wildcard imports
should use them, and tell the IDE not to warn on it.
Whether they "should" or not, I rather think they tend to.
You've got this IDE with about a jillion configurable behaviors,
and you only tweak those that are actual pain points. If you
prefer wildcard imports strongly enough to spend the time finding
the proper knob you'll do so -- but if it doesn't bother you that
much you won't, and the default will win.
Case in point: Me, the exemplar of lazy programmers. Some
years ago NetBeans would use wildcards if you imported N or more
classes from the same package, individual imports for fewer. At
the time, I spent the small effort to find where N was configured,
and adjusted the threshold a little. But in recent NetBeans
versions that configuration has either vanished or moved somewhere
else, and guess what? I haven't spent the time to try to find it,
but have simply gone with the flow and let NetBeans manage the
imports as it chooses. It means that in some of my .java files you
need to scroll a fair way down before you find anything interesting,
which is a little irritating -- but not irritating enough to get me
to try to do something about it.
(An ironic oddity: In NetBeans, if you refactor a class by moving
it from oldpackage to newpackage, NB adds `import oldpackage.*;' so
any oldpackage classes -- that used to be imported automatically
under the "same package" rule -- are still available in newpackage.
Then when you edit the refactored file, NB complains about the
wildcard import ...)
I would perhaps be too lazy to do single class imports without IDE support.
For me, you can delete the "perhaps." Lacking IDE help, I'd
use wildcard imports all over the place to duck the effort of
staying up-to-date with every single class. And I might get unlucky
when the java.io.Wotsit class appears next year ...
Personally, I prefer specific class imports because that way the imports
give a quick overview of the external features the class uses.
When it's a shortish list, yes. When you're writing Swing code,
you may find that the import list is so long as to be obfuscatory
rather than explanatory.
--
Eric Sosman
esosman@ieee-dot-org.invalid