Why so many imports instead of java.io.* ?

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.

Thank you,
Timothy Madden

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.

--
Eric Sosman
esosman@ieee-dot-org.invalid

On 08/14/2012 08: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 ?
>
I suspect it boils down to one of: "I want to.", I have to.", or "Huh?".

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.

I would perhaps be too lazy to do single class imports without IDE support.

Personally, I prefer specific class imports because that way the imports
give a quick overview of the external features the class uses.

Patricia

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

Timothy Madden wrote:
> Is it just me or people tend to enumerate all the needed classes for a
> Java source file each in its own import line ?

There is a strong indication that import-on-demand is not as good a
practice as single-type imports.

<http://javadude.com/articles/importondemandisevil.html>
<http://www.javabestpractice.com/java/disadvantage-of-using-wildcards-in-java-import-statements.html>

"Using single-type imports is quite useful and an absolute requirement in the open source community as this code is usually really reviewed. Using single-type imports makes it easy for the code reader to quickly find out the package a particular type is in: You just search for the type name from thestart of the source file."
<http://jalopy.sourceforge.net/existing/imports.html>

For arguments on both sides:
<http://stackoverflow.com/questions/147454/why-is-using-a-wild-card-with-a-java-import-statement-bad>

And in general, why not do a search yourself across the InterWebz?
<http://lmgtfy.com/?q=java+import+on+demand+vs.+single-type+import>

> 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.*
> ?

Less confusion, elimination of simple-name collisions, more explicit
documentation of what types it uses.

> Which, by the way, also needs no maintenance in case a new class or
> exception is needed in the file at a later time.

Not true.

It will need maintenance if that type name conflicts with another.

You don't actually need any import directives in a program at all.

The maintenance required for single-type import is negligible and not
worth avoiding.

--
Lew

On Tue, 14 Aug 2012 15:23:02 +0300, Timothy Madden
<terminatorul@gmail.com> wrote, quoted or indirectly quoted someone
who said :

>Which, by the way, also needs no maintenance in case a new class or
>exception is needed in the file at a later time.

My IDE, IntelliJ lets me configure how many classes it should take to
collapse to *.

It pretty well handles inserting them automatically. It is nice to
have the list spelled out. You can tell quite a bit about what a
class does just by looking at the import list.

* can get you in trouble e.g. List which has two completely different
meanings.
--
Roedy Green Canadian Mind Products http://mindprod.com
A new scientific truth does not triumph by convincing its opponents and making them see the light,
but rather because its opponents eventually die, and a new generation grows up that is familiar with it.
~ Max Planck 1858-04-23 1947-10-04

On 08/15/2012 02:31 AM, Lew wrote:
> Timothy Madden wrote:
>> Is it just me or people tend to enumerate all the needed classes for a
>> Java source file each in its own import line ?
>
> There is a strong indication that import-on-demand is not as good a
> practice as single-type imports.
>
> <http://javadude.com/articles/importondemandisevil.html>
> <http://www.javabestpractice.com/java/disadvantage-of-using-wildcards-in-java-import-statements.html>
>
> "Using single-type imports is quite useful and an absolute requirement in the open source community as this code is usually really reviewed. Using single-type imports makes it easy for the code reader to quickly find out the package a particular type is in: You just search for the type name from the start of the source file."
> <http://jalopy.sourceforge.net/existing/imports.html>
>
> For arguments on both sides:
> <http://stackoverflow.com/questions/147454/why-is-using-a-wild-card-with-a-java-import-statement-bad>
>
> And in general, why not do a search yourself across the InterWebz?
> <http://lmgtfy.com/?q=java+import+on+demand+vs.+single-type+import>
>
>> 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.*
>> ?
>
> Less confusion, elimination of simple-name collisions, more explicit
> documentation of what types it uses.
>
>> Which, by the way, also needs no maintenance in case a new class or
>> exception is needed in the file at a later time.
>
> Not true.
>
> It will need maintenance if that type name conflicts with another.
>
> You don't actually need any import directives in a program at all.
>
> The maintenance required for single-type import is negligible and not
> worth avoiding.

Thank you,
After reading the links (one of wich is currently broken) I see that
import lists are a work-around for a language-design problem...

Though I still find import-list a problem for /all/ Java-language
programmers in the world (which is only made a little easier by proper
IDEs), I agree with the them now. They should be used for future
compatibility between your code and the Java run-time classes.

I guess this issue has been a minus for Sun/Oracle since JDK 1.2 onwards.

Timothy Madden