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.
"We're kind of on the level of crossword puzzle writers... And no one ever goes to them and gives them an award." ~Joe Strummer sscce.org
Joined: Sep 02, 2000
thanks a lot for your reply guys. but why does not complile
while does [ November 08, 2005: Message edited by: kwame Iwegbue ]
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.
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).
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 ]
Originally posted by Jeff Albrechtsen: The following line doesn't have the effect you probably expect:
That line will search for packagejava.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:
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.
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.
Joined: Sep 16, 2005
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.
Joined: Sep 16, 2005
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: