This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes Beginning Java and the fly likes import statement Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "import statement" Watch "import statement" New topic
Author

import statement

kwame Iwegbue
Ranch Hand

Joined: Sep 02, 2000
Posts: 197
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 ]

Who dares, wins! (SAS motto)
Jeff Albertson
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
The following line doesn't have the effect you probably expect:

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:

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


There is no emoticon for what I am feeling!
marc weber
Sheriff

Joined: Aug 31, 2004
Posts: 11343

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
    kwame Iwegbue
    Ranch Hand

    Joined: Sep 02, 2000
    Posts: 197
    thanks a lot for your reply guys.
    but why does
    not complile

    while
    does
    [ November 08, 2005: Message edited by: kwame Iwegbue ]
    marc weber
    Sheriff

    Joined: Aug 31, 2004
    Posts: 11343

    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
    Ranch Hand

    Joined: Sep 02, 2000
    Posts: 197
    thanks a lot guys
    got it now, finally!

    now unto my next big question...
    Tony Morris
    Ranch Hand

    Joined: Sep 24, 2003
    Posts: 1608

    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).





    Tony Morris
    Java Q&A (FAQ, Trivia)
    Stuart Ash
    Ranch Hand

    Joined: Oct 07, 2005
    Posts: 637
    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 ]

    ASCII silly question, Get a silly ANSI.
    jayram joshi
    Greenhorn

    Joined: Aug 05, 2000
    Posts: 23
    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
    Java Cowboy
    Saloon Keeper

    Joined: Aug 16, 2005
    Posts: 14074
        
      16

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

    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:

    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.


    Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
    Scala Notes - My blog about Scala
    Jesper de Jong
    Java Cowboy
    Saloon Keeper

    Joined: Aug 16, 2005
    Posts: 14074
        
      16

    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.

    Jeff Albertson
    Ranch Hand

    Joined: Sep 16, 2005
    Posts: 1780
    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
    Ranch Hand

    Joined: Sep 16, 2005
    Posts: 1780
    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:
     
    I agree. Here's the link: http://aspose.com/file-tools
     
    subject: import statement
     
    Similar Threads
    what is the difference between importing and the extending statements
    What does Class.forName do?
    Top Level Nested class
    static import
    converting a string into a date