import statement

[kwame Iwegbue]

can someone please explain the difference b/w an import statement that uses the wild card(*), and one that just imports the specific class?

for example using either-

import java.util.*;
or
import java.util.Calendar.*;

Calendar methods, fields are not recognized, but using

import java.util.Calender;

they are recognised
[ November 08, 2005: Message edited by: kwame Iwegbue ]

[Jeff Albertson]

The following line doesn't have the effect you probably expect:

import java.util.Calendar.*

That line will search for package java.util.Calendar, and there is no such package.
It doesn't generate an error, but it has no effect. Perhaps you meant
the 1.5 static import:

import static java.util.Calendar.*

With this you can write getInstance() instead of Calendar.getInstance()
and MONDAY instead of Calendar.MONDAY. Don't abuse it!

[marc weber]

The wildcard version, import java.util.*; makes all java.util package components (classes and interfaces) "visable" to the compiler.

The non-wildcard version, import java.util.Calendar; limits the visability to a specific class or interface -- in this case, Calendar.

Avoiding wildcards has (at least) two advantages:

Avoiding wildcards makes it clear exactly why the import statement is there. For example, import java.util.*; might have been added for Collection, Date, Random... Who knows? On the other hand, import java.util.Calendar; makes the purpose obvious.

Avoiding wildcards lessens the chance of name collisions. For example, if you import java.awt.*; and import java.util.*; and then use the type "List," there will be a collision, because both packages include a List. Explicitly identifying the classes or interfaces to be imported could avoid this.

[kwame Iwegbue]

thanks a lot for your reply guys.
but why does

 import java.util.Calendar.*; 

not complile

while

 import java.util.Calendar; 

does
[ November 08, 2005: Message edited by: kwame Iwegbue ]

[marc weber]

import java.util.Calendar.*; should not generate a compilation error by itself; but if your code attempts to use Calendar with this import statement, then the attempted usage will generate an error.

As Jeff explained above, the wildcard will cause the compiler will look for a package called java.util.Calendar. But it won't find anything, because the package is simply java.util. And because java.util is not imported by the above statement, attempting to use Calendar will generate an error.

So...

import java.util.Calendar; will import the Calendar class, but nothing else in java.util.

import java.util.*; will import the contents of the java.util package, which includes Calendar.

import java.util.Calendar.*; will do nothing, because there is no such package. Attempting to use Calendar will then cause an error.

[kwame Iwegbue]

thanks a lot guys
got it now, finally!

now unto my next big question...

[Tony Morris]

import java.util.Calendar.*; will do nothing, because there is no such package. Attempting to use Calendar will then cause an error.

import java.util.Calendar.*; will do nothing, because it imports all direct nested types of java.util.Calendar. Attempting to use Calendar may or may not cause a compile-time error, depending on whether or not it has been imported (assuming you're using the unqualified name).

// compiles
import java.util.Calendar.*;
import java.util.Calendar;
 
class X
{
Calendar c;
}

// does not compile
import java.util.Calendar.*;
 
class X
{
Calendar c;
}

[Stuart Ash]

It's funny that import java.util.Calendar.*; works. Why would this be compilable? Isn't it more logical for the compiler to disallow pkg.classname.* ??
[ November 09, 2005: Message edited by: Stuart Ash ]

[jayram joshi]

That is because compiler has no way of figuring out that
import java.util.Calendar.* actually is of form pkg.classname.* and not package.*

[Jesper de Jong]

Originally posted by Jeff Albrechtsen:
The following line doesn't have the effect you probably expect:

import java.util.Calendar.*

That line will search for package java.util.Calendar, and there is no such package.
It doesn't generate an error, but it has no effect. Perhaps you meant
the 1.5 static import:

import static java.util.Calendar.*

With this you can write getInstance() instead of Calendar.getInstance()
and MONDAY instead of Calendar.MONDAY. Don't abuse it!

Please forget about static import. It's a new Java 5.0 feature that is too easy to misuse. You should only use it so that you don't have to use the Constant Interface AntiPattern (see Effective Java, Item 17), and not for anything else.

[Jesper de Jong]

Originally posted by Stuart Ash:
It's funny that import java.util.Calendar.*; works. Why would this be compilable? Isn't it more logical for the compiler to disallow pkg.classname.* ??

[ November 09, 2005: Message edited by: Stuart Ash ]

With import java.util.Calendar.*; you import the inner classes of class Calendar. Most of the time that's not very useful, but I know of one instance where it is: the inner class Entry in interface Map.

import java.util.Map;
import java.util.Map.Entry; // could also have typed java.util.Map.*
 
public void printMap(Map m) {
  for (Iterator i = map.entrySet().iterator(); i.hasNext(); ) {
    Entry e = i.next();
    System.out.println("key=" + e.getKey + ", value=" + e.getValue());
  }
}

[Jeff Albertson]

Thanks to Jesper and Tony for pointing out my mistake: import java.util.Calendar.*;
attempts to import all the directly nested types in Calendar.
And in this case there are none... Crazy syntax! imagine if someone
didn't follow the captilisation naming convention: import com.acme.foo.*;
could either be importing from package foo or importing the directly nested types
of type foo! The ambiguity bugged me so much that I tried to create
a package com.acme.foo and a class foo in package com.acme, but the
compiler comes back with the error "the type foo collides with a package"
*whew* (where's the graemlin for wipes-sweat-off-brow?)

As for the static import with wildcard, I agree that it's best avoided. When
I use an IDE, I use no wildcards at all in my imports, because the IDE
makes it easy to maintain -- to add, order and prune unused ones. But
if I'm whipping up a little test code in TextPad, I appreciate not having
to always be so tidy.

[Jeff Albertson]

I should add that it's the wildcard aspect of "static import with wildcard"
that's bad. This is OK by me, if you need to use a constant heavily:

  
import static java.lang.Math.PI;
 
...
area = PI * r * r;
...