Win a copy of The Java Performance Companion this week in the Performance forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

import statement

 
kwame Iwegbue
Ranch Hand
Posts: 197
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 1780
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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!
 
marc weber
Sheriff
Posts: 11343
Java Mac Safari
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    Ranch Hand
    Posts: 197
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 11343
    Java Mac Safari
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 197
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    thanks a lot guys
    got it now, finally!

    now unto my next big question...
     
    Tony Morris
    Ranch Hand
    Posts: 1608
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

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



     
    Stuart Ash
    Ranch Hand
    Posts: 637
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Greenhorn
    Posts: 23
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Pie
    Posts: 15369
    40
    Android IntelliJ IDE Java Scala Spring
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Jesper de Jong
    Java Cowboy
    Saloon Keeper
    Pie
    Posts: 15369
    40
    Android IntelliJ IDE Java Scala Spring
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 1780
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Posts: 1780
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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:
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic