why not import everything?

[yawnmoth]

Is there a particular reason why Java doesn't automatically do "import
java.*" for all programs? It can be specified manually, but I'm just
wondering why Java doesn't already do it. Indeed, there are quite a
few Java apps that don't do this and, instead, import classes one
import statement at a time.

 

[Mark Space]

Is there a particular reason why Java doesn't automatically do "import
java.*" for all programs? It can be specified manually, but I'm just

Nope, "import java.*" won't actually import anything. Java packages
aren't hierarchical. That means if you import java.util.* you won't get
anything from java.util.concurrent, for example, because it's a
different package.

wondering why Java doesn't already do it. Indeed, there are quite a
few Java apps that don't do this and, instead, import classes one
import statement at a time.

No apps do this, because it doesn't work, as I said above.

As for why the language designers don't allow it, what about name space
collisions? Isn't that the whole point of packages, to manage
namespaces? Why obviate that with a global import?

For example, what about java.util.Date? If you do a global import, you
can never have another Date class. Thus, the java.sql.Date folks would
be out of luck. Then we'd saddled with stupid names for all classes,
like JavaDate and SqlDate and PleaseDontNameYourClassDate.

Sorry, but this is a very silly question.

 

[Joshua Cranmer]

Is there a particular reason why Java doesn't automatically do "import
java.*" for all programs? It can be specified manually, but I'm just
wondering why Java doesn't already do it. Indeed, there are quite a
few Java apps that don't do this and, instead, import classes one
import statement at a time.

As was mentioned earlier, |import java.*| doesn't actually do anything.
But let's assume you meant something more like |import java.util.*|.

So why are so-called star imports frowned upon? Several reasons.

First, name collisions. If I import all of java.util and java.awt, what
do I mean when I refer to List, the collections interface or the toolkit
widget? Such an import, in short, ruins one of the primary reasons for
namespaces: to avoid name collisions.

Another reason is that it makes code harder to read. If I'm not quite
sure where ObscureClassName is held, and I go up and see |import
org.acme.foobar.*| and |import org.evilgenius.foobaz.*| I'm none the
wiser. But if I see |import org.acme.foobar.ObscureClassName|, I can
instantly tell in which package it is.

It's also a little more aesthetically pleasing, especially if you're
only importing one or two classes. If you have to import many classes,
that's when the star imports become useful. But if you're getting to
that point, it may be indicating something about your package structure.

 

[Lew]

Nope, "import java.*" won't actually import anything. Java packages
aren't hierarchical. That means if you import java.util.* you won't get
anything from java.util.concurrent, for example, because it's a
different package.




No apps do this, because it doesn't work, as I said above.

As for why the language designers don't allow it, what about name space
collisions? Isn't that the whole point of packages, to manage
namespaces? Why obviate that with a global import?

For example, what about java.util.Date? If you do a global import, you
can never have another Date class. Thus, the java.sql.Date folks would
be out of luck. Then we'd saddled with stupid names for all classes,
like JavaDate and SqlDate and PleaseDontNameYourClassDate.

Sorry, but this is a very silly question.

Best practice is to import single identifiers, not use import-on-demand.

What is the advantage of what the OP suggests? I suggest there isn't one.

 

[Knute Johnson]

Best practice is to import single identifiers, not use import-on-demand.

I don't know about that. Why would they give you the capability to
import a whole package and then not want you to use it? On the
contrary, writing all those import statements is sort of silly when you
can just import the package. The compiler is smart enough to tell you
if there is a conflict.

What is the advantage of what the OP suggests? I suggest there isn't one.

The biggest advantage would be for those of us that don't use the fancy
IDE's that automatically create the import statements. The risk of
conflicts is small and the one I run into most often is java.util.List
and javax.swing.List. That isn't solved by using class import
statements, so I have to specify the package name for the class anyway.

I think it would be quite handy to have an "import all packages" statement.

 

[yawnmoth]

As was mentioned earlier, |import java.*| doesn't actually do anything.
But let's assume you meant something more like |import java.util.*|.

So why are so-called star imports frowned upon? Several reasons.

First, name collisions. If I import all of java.util and java.awt, what
do I mean when I refer to List, the collections interface or the toolkit
widget? Such an import, in short, ruins one of the primary reasons for
namespaces: to avoid name collisions.

To fix resolve issue of collisions, Java could always disambiguate by
requiring people refer to util.List and awt.List instead of List or
java.util.List. ie. start at the name of the class and go backwards
until you find the minimally unique identifier for that object.

 

[Arne Vajhøj]

Best practice is to import single identifiers, not use import-on-demand.

What is the advantage of what the OP suggests? I suggest there isn't one.

Fewer lines of code.

So wildcard import is sometimes used for 50 lines demo code.

It does not belong in real code.

And even in demo code wildcard import is becoming rare, because
IDE's today are capable of suggesting the correct imports, when you use
a class.

Arne

 

[Arne Vajhøj]

I don't know about that. Why would they give you the capability to
import a whole package and then not want you to use it? On the
contrary, writing all those import statements is sort of silly when you
can just import the package. The compiler is smart enough to tell you
if there is a conflict.

There is a difference between language syntax and best practice. Not
only in this case but in many other cases.

The best practice of not using wildcard imports is widely
recognized.

The biggest advantage would be for those of us that don't use the fancy
IDE's that automatically create the import statements.

I think it would be quite handy to have an "import all packages" statement.

For real code the time to write lots imports would be insignificant
for the project.

And since free IDE's are available, then I would consider it a choice
not to use one.

Arne

 

[Arne Vajhøj]

To fix resolve issue of collisions, Java could always disambiguate by
requiring people refer to util.List and awt.List instead of List or
java.util.List. ie. start at the name of the class and go backwards
until you find the minimally unique identifier for that object.

Java already does something like that.

But the language should not be changed to create more problems.

Clarity should take precedence over reducing typing.

Arne

 

[Arne Vajhøj]

I think it would be quite handy to have an "import all packages" statement.

In the best or worst ant tradition:

import **.*;



Arne

 

[Lew]

To fix resolve issue of collisions, Java could always disambiguate by
requiring people refer to util.List and awt.List instead of List or
java.util.List. ie. [sic] start at the name of the class and go backwards
until you find the minimally unique identifier for that object.

But it doesn't, and it won't.

Packages are namespaces, and not actually hierarchical.

 

[Mike Schilling]

I don't know about that. Why would they give you the capability to
import a whole package and then not want you to use it? On the
contrary, writing all those import statements is sort of silly when
you can just import the package. The compiler is smart enough to
tell you if there is a conflict.

Of course, next month, when more classes have been added to those
packages, there *will* be a conflict and your code won't compile. But
that's OK; you (or whoever's now maintaining the code) will figure it
out. Eventually

 

[Knute Johnson]

But do you want to be told of the conflict, or would you
prefer not to have a conflict at all?

Here's a scenario: You write "import java.util.*;" and
"import knute.util.TernaryTree;" and then write references
to the unqualified "TernaryTree" class all over the place,
happy that you're getting your own class. All is well, the
compiler is happy, the unit tests succeed, and the Sun shines.

... until Java 1.9 comes out, and lo! the java.util package
has a brand-new "TernaryTree" class (or interface) and the
compiler starts whining about code that has been running happily
for two years since anyone last looked at it. Worse, the person
who encounters the problem is not really a Java programmer, but
a webmaster who's just trying to deploy his old applications on a
new application server. All he gets is some cryptic error message
about "Server failure: please contact site administrator" referring
to an application that a long-gone consultant wrote.

Would it not have been better to "import java.util.Map;" and
"import java.util.HashMap;" if those were the only two you needed?
(Of course, even with minimal importing you'd still be out of luck
if a "java.lang.TernaryTree" ever appeared -- nothing's perfect.)


ITYM "java.awt.list", but we get the point. The conflict risk
is small, perhaps, but it could be even smaller with little extra
effort. I confess that I myself sometimes use a wildcard import
in Swing programming, since you wind up using so many Swing classes
and interfaces that the individual imports become tedious even with
a helpful IDE, but with that lone exception I've found individual
imports quite acceptable.


To me, that sounds equivalent to having no import statement at
all and using FQN's everywhere. How many conflicts would there be
if you did the equivalent right now (start your code with a long
string of wildcard import statements for every package)? Off the
top of my head I can think of List and Date as classes/interfaces
I use often enough that I'd prefer not to write FQN's every single
time. How many others? In a quick scan of the Javadoc I find
two kinds of Annotation, two kinds of AnySeqHelper, two kinds of
Array, two kinds of ArrayType, four kinds of Attribute and three
kinds of Attributes, two kinds of AttributeSet, two kinds of
AuthenticationException -- I'm only in the A's, Knute, and there
are already too many conflicts for my peace of mind.

I hear you but this is one of those things that really doesn't matter in
the long run. And you wouldn't have to use it all the time just when it
was advantageous, like the package imports.

I would be very curious to know if Sun has added any name conflicted
classes in recent history. I can't think of any off the top of my head
but that's not saying much .

 

[Roedy Green]

Is there a particular reason why Java doesn't automatically do "import
java.*" for all programs? It can be specified manually, but I'm just
wondering why Java doesn't already do it. Indeed, there are quite a
few Java apps that don't do this and, instead, import classes one
import statement at a time.

The import statement is good documentation on just what a class does.
You can tell at a glance if it does any I/O for example or if it has a
GUI.

You CAN'T import both java.awt.List and java.util.List. One function
of import is to resolve ambiguous class names.
--
Roedy Green Canadian Mind Products
http://mindprod.com

"By 2040, the Sahara will be moving into Europe, and Berlin
will be as hot as Baghdad. Atlanta will end up a kudzu
jungle. Phoenix will become uninhabitable, as will parts of
Beijing (desert), Miami (rising seas) and London (floods).
Food shortages will drive millions of people north, raising
political tensions."
~ James Lovelock
Lovelock is more pessimistic than the consensus, because he thinks man will
refuse to take significant action to ameliorate global warming.

 

[Daniel Pitts]

Is there a particular reason why Java doesn't automatically do "import
java.*" for all programs? It can be specified manually, but I'm just
wondering why Java doesn't already do it. Indeed, there are quite a
few Java apps that don't do this and, instead, import classes one
import statement at a time.

Everything in the package java.lang is already automatically imported.

Other things should be specified on an as-needed basis. This is both
for compile speed, and as a prevention of maintainer headaches.

 

[Daniel Pitts]

I don't know about that. Why would they give you the capability to
import a whole package and then not want you to use it? On the
contrary, writing all those import statements is sort of silly when you
can just import the package. The compiler is smart enough to tell you
if there is a conflict.

It can tell you that there is a conflict today, but not that there will
be one tomorrow. What happens when a new conflict arises because a
package was augmented? The maintainer then has to figure out which
class was the intended class.

The biggest advantage would be for those of us that don't use the fancy
IDE's that automatically create the import statements. The risk of
conflicts is small and the one I run into most often is java.util.List
and javax.swing.List. That isn't solved by using class import
statements, so I have to specify the package name for the class anyway.

I think you mean java.awt.List, but the point remains.

I think it would be quite handy to have an "import all packages" statement.

That might work for the "write once, never maintain" software, which no
successful software falls under that category, by definition.

Remember, writing a program is a lot like writing a book. It is going to
be read a lot more often than it is going to be written, spending twice
as long to make it even 10% more readable is *well* worth it.

I let my IDE show me a list of possible imports, and usually don't allow
it to specify "*" for anything. Even without an IDE, meanually
importing 5 classes is easier than remembering which package those 5
classes may have come from, later on when I'm updating.

 

[Lew]

But:

     -- How often does that really happen?  I'm not suggesting it never  
does, but engaging in a dogmatic philosophy in order to make things  
slightly easier in rare circumstances isn't necessarily a slam-dunk  
argument

I've had it happen to me more than once.

 

[Lew]

I've had it happen to me more than once.

I reread this and have to correct myself. What has happened to me is
that I've maintained code with multiple wildcard imports and not been
sure which package holds the imported type.

 

[Mike Schilling]

As for the issue you describe, I agree there's value in being able
to
know where a type came from. But a good IDE should be able to tell
you for a given type that's uniquely resolvable in the code where it
came from.

There's a paradox of sorts here.

Without IDEs it's more of a pain in the butt to do single-class
imports, but it's much more important to do so. Without it, it's very
difficult for the maintainer to find what package the class lives in.
(Obviously, ArrayList isn't a problem. I'm thinking more of a large
system with lots of classes that aren't in the java.... hierarchy.)

With IDEs, it's trivial to do the single-class import, but also
trivial to find the class; just point to it and click.

However, when working on a large system, it is unacceptable to create
a situation where programmer A's addtion of a new class breaks
programmer B's code. Neither A nor the person in charge of building
the system as a whole should be expected to go to B's code and figure
out how to get it working again.

 

[blueparty]

Is there a particular reason why Java doesn't automatically do "import
java.*" for all programs? It can be specified manually, but I'm just
wondering why Java doesn't already do it. Indeed, there are quite a
few Java apps that don't do this and, instead, import classes one
import statement at a time.

First, there are classes (interfaces) with the same name, like
java.awt.List and java.util.List. If everything was imported you would
always need to use full qualified name like: java.awt.List lst; and keep
checking for conflicting names.

Then, more often than not, you need to import your own packages, which
are, probably, not java.*, but still need to be imported.

B