Disadvantage of using wildcards in import statement.

Discussion in 'Java' started by Dipankar, Sep 8, 2006.

  1. Dipankar

    Dipankar Guest

    Hi,

    Recently I wrote a certification test for Java2. There was a question
    on using wildcards in import statement with four options. Only one
    among them is correct (as per the test paper).
    I was not very sure about the answer.

    Can anyone help me in finding the answer?

    Question

    import java.util.*;

    What is the disadvantage of using "*" in an import statement as shown
    in the sample above?

    Choice 1 : The class file is less portable.
    Choice 2 : The Java Virtual Machine takes slightly longer to
    validate the class file.
    Choice 3 : The maximum number of classes allowed to be imported is
    limited to 128.
    Choice 4 : The code dependencies are difficult to evaluate from
    reading the code.
    Choice 5 : The Java Virtual Machine takes slightly longer to load the
    class file.

    According to me the Choice 4 is correct. But I am not sure about the
    impact on JVM while using wildcards.

    Thanks in advance.
     
    Dipankar, Sep 8, 2006
    #1
    1. Advertising

  2. Dipankar

    jiji Guest

    Hi,

    wildcards in import statement may slow down the compilation process. It
    doesnt have any impact on performance of the application at run time.

    Actually, the imported classes bytecode wont be bundled or included
    with ur class. the import is more for resolving the actual class u r
    refering in ur code..

    ~Jiji
     
    jiji, Sep 8, 2006
    #2
    1. Advertising

  3. Dipankar wrote:
    > Hi,
    >
    > Recently I wrote a certification test for Java2. There was a question
    > on using wildcards in import statement with four options. Only one
    > among them is correct (as per the test paper).
    > I was not very sure about the answer.
    >
    > Can anyone help me in finding the answer?
    >
    > Question
    >
    > import java.util.*;
    >
    > What is the disadvantage of using "*" in an import statement as shown
    > in the sample above?
    >
    > Choice 1 : The class file is less portable.
    > Choice 2 : The Java Virtual Machine takes slightly longer to
    > validate the class file.
    > Choice 3 : The maximum number of classes allowed to be imported is
    > limited to 128.
    > Choice 4 : The code dependencies are difficult to evaluate from
    > reading the code.
    > Choice 5 : The Java Virtual Machine takes slightly longer to load the
    > class file.
    >
    > According to me the Choice 4 is correct. But I am not sure about the
    > impact on JVM while using wildcards.
    >
    > Thanks in advance.
    >


    Java import statements are a compile time mechanism for mapping a simple
    name such as "List" to a qualified name such as "java.util.List". I'm
    not aware of any impact at all on the JVM.

    Patricia
     
    Patricia Shanahan, Sep 8, 2006
    #3
  4. Dipankar

    Chris Smith Guest

    Patricia Shanahan <> wrote:
    > Java import statements are a compile time mechanism for mapping a simple
    > name such as "List" to a qualified name such as "java.util.List". I'm
    > not aware of any impact at all on the JVM.


    In fact, the JVM class file specification leaves little room for
    compiled binary code to even contain any indications of what imports
    were used in the source. Of course one can't specify that the
    performance has to be equal -- so technically it's not guaranteed -- but
    it would require something malicious for a compiler to actually generate
    slower code due to imports.

    --
    Chris Smith
     
    Chris Smith, Sep 8, 2006
    #4
  5. Dipankar

    Neil Padgen Guest

    Dipankar wrote:
    > Hi,
    >
    > Recently I wrote a certification test for Java2. There was a question
    > on using wildcards in import statement with four options. Only one
    > among them is correct (as per the test paper).
    > I was not very sure about the answer.
    >
    > Can anyone help me in finding the answer?
    >
    > Question
    >
    > import java.util.*;
    >
    > What is the disadvantage of using "*" in an import statement as shown
    > in the sample above?
    >
    > Choice 1 : The class file is less portable.
    > Choice 2 : The Java Virtual Machine takes slightly longer to
    > validate the class file.
    > Choice 3 : The maximum number of classes allowed to be imported is
    > limited to 128.
    > Choice 4 : The code dependencies are difficult to evaluate from
    > reading the code.
    > Choice 5 : The Java Virtual Machine takes slightly longer to load the
    > class file.
    >
    > According to me the Choice 4 is correct. But I am not sure about the
    > impact on JVM while using wildcards.
    >
    > Thanks in advance.
    >


    It's not just that code dependencies are difficult to evaluate: your
    code might suddenly fail to compile.

    Consider the following:

    /* Bar.java */
    package foo;

    import java.util.*;

    public class Bar {
    public void baz() {
    List ambiguousList = new ArrayList();
    }
    }
    /* end Bar.java */

    This compiles fine ... until I create a new class List in package foo.

    $ javac *.java
    Bar.java:7: incompatible types
    found : java.util.ArrayList
    required: foo.List
    List ambiguousList = new ArrayList();
    ^
    1 error

    -- Neil
     
    Neil Padgen, Sep 8, 2006
    #5
  6. Dipankar

    Guest


    > It's not just that code dependencies are difficult to evaluate: your
    > code might suddenly fail to compile.


    Some long time ago I worked in a project that had it's own class
    Currency. Then came JDK 1.4 and it's new class java.util.Currency. And
    of course there were "import java.util.*" everywhere. We had to fix a
    few hundert source files.

    We used a script for that task (thanks sed), but it wasn't nice.

    I think, with modern Java IDEs managing imports almost automatically,
    there is no sound reason for using wildcard imports anymore.

    Best regards,
    Ralf.
     
    , Sep 10, 2006
    #6
  7. wrote:
    > Some long time ago I worked in a project that had it's own class
    > Currency. Then came JDK 1.4 and it's new class java.util.Currency. And
    > of course there were "import java.util.*" everywhere. We had to fix a
    > few hundert source files.
    >
    > We used a script for that task (thanks sed), but it wasn't nice.
    >
    > I think, with modern Java IDEs managing imports almost automatically,
    > there is no sound reason for using wildcard imports anymore.


    Not in production code.

    Code snippets to news groups maybe.

    :)

    Wildcard imports should get shot down at the code
    review.

    Or even better by an automatic style checker run before
    the code get into code review.

    Arne
     
    =?ISO-8859-1?Q?Arne_Vajh=F8j?=, Sep 10, 2006
    #7
  8. Dipankar

    Daniel Dyer Guest

    On Sun, 10 Sep 2006 18:50:09 +0100, Arne Vajhøj <> wrote:
    > Wildcard imports should get shot down at the code
    > review.
    >
    > Or even better by an automatic style checker run before
    > the code get into code review.


    IDEA has the option to optimise imports when it commits any changes to
    version control. Your imports will be updated to match your configured
    preferences (so expand wildcards and remove unused imports). Presumably
    Eclipse has something similar (and NetBeans too)?

    Dan.

    --
    Daniel Dyer
    http://www.dandyer.co.uk
     
    Daniel Dyer, Sep 10, 2006
    #8
  9. Daniel Dyer wrote:
    > IDEA has the option to optimise imports when it commits any changes to
    > version control. Your imports will be updated to match your configured
    > preferences (so expand wildcards and remove unused imports). Presumably
    > Eclipse has something similar (and NetBeans too)?


    Interesting.

    But I am so oldfashioned that I do not like if my code
    is changed behind my back by a tool.

    Arne
     
    =?UTF-8?B?QXJuZSBWYWpow7hq?=, Sep 10, 2006
    #9
  10. Dipankar

    IchBin Guest

    Arne Vajhøj wrote:
    > Daniel Dyer wrote:
    >> IDEA has the option to optimise imports when it commits any changes to
    >> version control. Your imports will be updated to match your
    >> configured preferences (so expand wildcards and remove unused
    >> imports). Presumably Eclipse has something similar (and NetBeans too)?

    >
    > Interesting.
    >
    > But I am so oldfashioned that I do not like if my code
    > is changed behind my back by a tool.
    >
    > Arne


    Well I hate to tell you this but Eclipse and NetBeans can also
    automatically build your import statements.

    I am old fashioned too but it nice to use these tools for at least when
    you open the program you can tell right upfront what classes the code is
    using. For Eclipse it has been able to do this for more than two years.
    Netbeans just added to their IDE.

    So it is a proven functional part of a professional IDE.

    --
    Thanks in Advance...
    IchBin, Pocono Lake, Pa, USA http://weconsultants.phpnet.us
    'If there is one, Knowledge is the "Fountain of Youth"'
    -William E. Taylor, Regular Guy (1952-)
     
    IchBin, Sep 10, 2006
    #10
  11. IchBin wrote:
    > Arne Vajhøj wrote:
    >> Daniel Dyer wrote:
    >>> IDEA has the option to optimise imports when it commits any changes
    >>> to version control. Your imports will be updated to match your
    >>> configured preferences (so expand wildcards and remove unused
    >>> imports). Presumably Eclipse has something similar (and NetBeans too)?

    >>
    >> Interesting.
    >>
    >> But I am so oldfashioned that I do not like if my code
    >> is changed behind my back by a tool.

    >
    > Well I hate to tell you this but Eclipse and NetBeans can also
    > automatically build your import statements.
    >
    > I am old fashioned too but it nice to use these tools for at least when
    > you open the program you can tell right upfront what classes the code is
    > using. For Eclipse it has been able to do this for more than two years.
    > Netbeans just added to their IDE.
    >
    > So it is a proven functional part of a professional IDE.


    I know and I use that feature all the time.

    But it has very little in common with what I commented on.

    I do not have a problem with the editor proposing
    something that I can view and modify if I want to.

    I have a problem if I look at the code, I think it is OK
    and I choose commit and then the editor change the code.

    Arne

    co
     
    =?UTF-8?B?QXJuZSBWYWpow7hq?=, Sep 11, 2006
    #11
  12. Dipankar

    Karl Uppiano Guest

    "Arne Vajhøj" <> wrote in message
    news:IU0Ng.37576$_q4.21203@dukeread09...
    > IchBin wrote:
    >> Arne Vajhøj wrote:
    >>> Daniel Dyer wrote:
    >>>> IDEA has the option to optimise imports when it commits any changes to
    >>>> version control. Your imports will be updated to match your configured
    >>>> preferences (so expand wildcards and remove unused imports).
    >>>> Presumably Eclipse has something similar (and NetBeans too)?
    >>>
    >>> Interesting.
    >>>
    >>> But I am so oldfashioned that I do not like if my code
    >>> is changed behind my back by a tool.

    >>
    >> Well I hate to tell you this but Eclipse and NetBeans can also
    >> automatically build your import statements.
    >>
    >> I am old fashioned too but it nice to use these tools for at least when
    >> you open the program you can tell right upfront what classes the code is
    >> using. For Eclipse it has been able to do this for more than two years.
    >> Netbeans just added to their IDE.
    >>
    >> So it is a proven functional part of a professional IDE.

    >
    > I know and I use that feature all the time.
    >
    > But it has very little in common with what I commented on.
    >
    > I do not have a problem with the editor proposing
    > something that I can view and modify if I want to.
    >
    > I have a problem if I look at the code, I think it is OK
    > and I choose commit and then the editor change the code.
    >
    > Arne
    >
    > co


    NetBeans does not automatically change import statements, but it will
    generate them for you, and arrange them alphabetically. I never type import
    statements by hand anymore. Net beans used to collapse down to wildcards
    after 5 (configurable) imports from the same package. I don't think they do
    that anymore.
     
    Karl Uppiano, Sep 11, 2006
    #12
  13. Dipankar

    Stefan Ram Guest

    wrote:
    >Some long time ago I worked in a project that had it's own class
    >Currency. Then came JDK 1.4 and it's new class java.util.Currency. And
    >of course there were "import java.util.*" everywhere. We had to fix a
    >few hundert source files.


    I believe that »Currency« should still refer to your local
    class, unless you write »import java.util.Currency« without
    the asterisk.
     
    Stefan Ram, Jul 31, 2009
    #13
  14. Dipankar

    Roedy Green Guest

    One nice feature if the IntelliJ IDE is you can configure when to use
    *. When you have fewer than that many packages, IntelliJ expands the
    wildcard into individual classes, so you have an explicit list for
    documentation. This gives a quick overview of what sorts of thing the
    class does.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "Patriotism is fierce as a fever, pitiless as the grave, blind as a stone, and as irrational as a headless hen."
    ~ Ambrose Bierce (born: 1842-06-24 died: 1914 at age: 71)
     
    Roedy Green, Aug 1, 2009
    #14
  15. Dipankar

    Lew Guest

    wrote:
    >> Some long time ago I worked in a project that had it's [sic] own class
    >> Currency. Then came JDK 1.4 and it's new class java.util.Currency. And
    >> of course there were "import java.util.*" everywhere. We had to fix a
    >> few hundert source files.


    Stefan Ram wrote:
    > I believe that »Currency« should still refer to your local
    > class, unless you write »import java.util.Currency« without
    > the asterisk.


    This is resolved unambiguously in
    <http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.5>

    --
    Lew
     
    Lew, Aug 1, 2009
    #15
  16. Dipankar

    Roedy Green Guest

    On Fri, 31 Jul 2009 20:34:33 -0400, Lew <> wrote,
    quoted or indirectly quoted someone who said :

    >This is resolved unambiguously in
    ><http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.5>



    It is? I know you are a much better language lawyer than average. How
    do you infer that from the statements there?
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "Patriotism is fierce as a fever, pitiless as the grave, blind as a stone, and as irrational as a headless hen."
    ~ Ambrose Bierce (born: 1842-06-24 died: 1914 at age: 71)
     
    Roedy Green, Aug 1, 2009
    #16
  17. Dipankar

    Lew Guest

    Stefan Ram wrote:
    > I believe that »Currency« should still refer to your local
    > class, unless you write »import java.util.Currency« without
    > the asterisk.


    Lew wrote, quoted or indirectly quoted someone who said:
    >> This is resolved unambiguously in
    >> <http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.5>


    Roedy Green wrote:
    > It is? I know you are a much better language lawyer than average. How
    > do you infer that from the statements there?


    Quoting the JLS chapter 7.5:
    > The example:
    >
    > import java.util.*;
    >
    > causes the simple names of all public types declared in the package java.util
    > to be available within the class and interface declarations of the compilation
    > unit. Thus, the simple name Vector refers to the type Vector in the package
    > java.util in all places in the compilation unit where that type declaration is
    > not shadowed (§6.3.1) or obscured (§6.3.2). The declaration might be shadowed
    > by a single-type-import declaration of a type whose simple name is Vector; by
    > a type named Vector and declared in the package to which the compilation unit
    > belongs; or any nested classes or interfaces.


    It's the part about the type being declared in the same package or and nested
    classes/interfaces shadowing the import-on-demand.

    --
    Lew
     
    Lew, Aug 1, 2009
    #17
  18. Lew wrote:
    > wrote:
    >>> Some long time ago I worked in a project that had it's [sic] own class
    >>> Currency. Then came JDK 1.4 and it's new class java.util.Currency. And
    >>> of course there were "import java.util.*" everywhere. We had to fix a
    >>> few hundert source files.

    >
    > Stefan Ram wrote:
    >> I believe that »Currency« should still refer to your local
    >> class, unless you write »import java.util.Currency« without
    >> the asterisk.

    >
    > This is resolved unambiguously in
    > <http://java.sun.com/docs/books/jls/third_edition/html/packages.html#7.5>


    Even with specific rules in the JLS, then it is still bad for
    readability.

    Arne
     
    Arne Vajhøj, Aug 1, 2009
    #18
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Joe
    Replies:
    3
    Views:
    4,456
    Sudsy
    Dec 5, 2003
  2. dorayme
    Replies:
    11
    Views:
    1,088
    Neredbojias
    Sep 21, 2005
  3. PenguinPig

    Disadvantage of Resource

    PenguinPig, Jun 24, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    370
    PenguinPig
    Jun 24, 2006
  4. Method Man

    Disadvantage of using 'inline'

    Method Man, Sep 24, 2004, in forum: C Programming
    Replies:
    18
    Views:
    621
    CBFalconer
    Sep 30, 2004
  5. deathweaselx86
    Replies:
    5
    Views:
    1,115
    Raymond Hettinger
    Jun 25, 2011
Loading...

Share This Page