Why we have to remove unused Import

Discussion in 'Java' started by Joey, Jul 18, 2006.

  1. Joey

    Joey Guest

    Hello Everyone.

    I want to know why we have to remove those unused Import, use
    java.util.ArrayList, don't use java.util.*, why we have to do this.
    just for good code style ? or ....


    Thanks.

    Joey.
     
    Joey, Jul 18, 2006
    #1
    1. Advertising

  2. "Joey" <> wrote in message
    news:...
    > Hello Everyone.
    >
    > I want to know why we have to remove those unused Import, use
    > java.util.ArrayList, don't use java.util.*, why we have to do this.
    > just for good code style ? or ....


    Using package imports can cause hidden problems. When
    you upgrade Java, or some other library, there may be
    new classes. The worst case is that you have a class with
    the same name as one of these, that has all the methods
    you use, and that does almost the same thing or is rarely
    used and rarely tested. So your project will compile, but
    will break at runtime in rare circumstances. For a large
    project, this is not as improbable as you might think. A
    more common case is that a new class with the same
    name as one you are using is introduced, but you are
    using methods it does not have, or it breaks in an
    immediate and obvious way at runtime.
     
    Larry Barowski, Jul 18, 2006
    #2
    1. Advertising

  3. Joey wrote:
    > Hello Everyone.
    >
    > I want to know why we have to remove those unused Import, use
    > java.util.ArrayList, don't use java.util.*, why we have to do this.
    > just for good code style ? or ....


    You usually don't HAVE to do this.

    The only case where importing too much is an error is when two package
    imports both cover the same name. The classic example is java.util.* and
    java.awt.*, which both have define "List".

    However, there are two motivations for keeping imports pruned:

    1. Avoiding future ambiguity. Recompiling with a new version of the SDK
    could introduce an ambiguity at an inconvenient time.

    2. Conveying information to readers of the program. Seeing the actual
    imported class list gives an impression of the sort of things the
    program does.

    Patricia
     
    Patricia Shanahan, Jul 18, 2006
    #3
  4. Joey

    IchBin Guest

    Patricia Shanahan wrote:
    > Joey wrote:
    >> Hello Everyone.
    >>
    >> I want to know why we have to remove those unused Import, use
    >> java.util.ArrayList, don't use java.util.*, why we have to do this.
    >> just for good code style ? or ....

    >
    > You usually don't HAVE to do this.
    >
    > The only case where importing too much is an error is when two package
    > imports both cover the same name. The classic example is java.util.* and
    > java.awt.*, which both have define "List".
    >
    > However, there are two motivations for keeping imports pruned:
    >
    > 1. Avoiding future ambiguity. Recompiling with a new version of the SDK
    > could introduce an ambiguity at an inconvenient time.
    >
    > 2. Conveying information to readers of the program. Seeing the actual
    > imported class list gives an impression of the sort of things the
    > program does.
    >
    > Patricia


    IMHO - Also, if say I pick up your program, after you have left the
    company, and look at the imports I can get a good feel on what to
    expect from the program.

    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, Jul 18, 2006
    #4
  5. Joey

    Guest

    Thanks everyone, I also want to know does unused import cause memory
    problem, I mean, it will use more memory?
     
    , Jul 18, 2006
    #5
  6. Joey

    Chris Uppal Guest

    wrote:

    > Thanks everyone, I also want to know does unused import cause memory
    > problem, I mean, it will use more memory?


    It might take a little more memory at compile-time (but why should you care ?).
    At runtime it makes exactly, mathematically, zero difference.

    -- chris
     
    Chris Uppal, Jul 18, 2006
    #6
  7. Joey

    Chris Uppal Guest

    IchBin wrote:

    > IMHO - Also, if say I pick up your program, after you have left the
    > company, and look at the imports I can get a good feel on what to
    > expect from the program.


    Personally, I consider the long lists of not-obviously related explicit imports
    that tools like Eclipse can cow you into creating to be /less/ clear than a few
    wildcard imports.

    And if the risk of a sudden "new" ambiguity is something that seriously bothers
    you ("you" not meant personally, of course) then there is something very
    seriously wrong with your project management.

    -- chris
     
    Chris Uppal, Jul 18, 2006
    #7
  8. Hi,

    wrote:
    > Thanks everyone, I also want to know does unused import cause memory
    > problem, I mean, it will use more memory?


    No.

    AFAIK, from the compiled class-file, you cannot see, if there were
    unused imports, because the compiler "removes" (*) them.

    Ciao,
    Ingo

    (*) For pedantic persons, "remove" is not the correct word in this case,
    but that does not matter ;-)
     
    Ingo R. Homann, Jul 18, 2006
    #8
  9. Hi,

    Larry Barowski wrote:
    >>I want to know why we have to remove those unused Import, use
    >>java.util.ArrayList, don't use java.util.*, why we have to do this.
    >>just for good code style ? or ....

    >
    >
    > Using package imports can cause hidden problems. When
    > you upgrade Java, or some other library, there may be
    > new classes. The worst case is that you have a class with
    > the same name as one of these, that has all the methods
    > you use, and that does almost the same thing or is rarely
    > used and rarely tested. So your project will compile, but
    > will break at runtime in rare circumstances. ...A
    > more common case is that a new class with the same
    > name as one you are using is introduced, but you are
    > using methods it does not have, or it breaks in an
    > immediate and obvious way at runtime.


    Eh... just a second...:

    Joey asked for *unused* imports. If they are unused, the problems you
    mention cannot occur!

    Ciao,
    Ingo
     
    Ingo R. Homann, Jul 18, 2006
    #9
  10. wrote:
    > Thanks everyone, I also want to know does unused import cause memory
    > problem, I mean, it will use more memory?
    >


    No difference at run time. All the imports do is tell the compiler how
    to calculate the fully qualified class name, such as "java.util.List",
    from an unqualified name such as "List".

    Patricia
     
    Patricia Shanahan, Jul 18, 2006
    #10
  11. Joey

    Tony Morris Guest

    On Mon, 17 Jul 2006 18:46:09 -0700, Joey wrote:

    > Hello Everyone.
    >
    > I want to know why we have to remove those unused Import, use
    > java.util.ArrayList, don't use java.util.*, why we have to do this.
    > just for good code style ? or ....
    >
    >
    > Thanks.
    >
    > Joey.


    There are a number of reasons and a few silly ones. It will slow down
    compilation time asymptotically and it will not affect runtime at all
    (classes are fully qualified in the class' bytecode constant_pool).

    The more important reasons relate to "encapsulation". First, if I were to
    read code that contains wildcard imports, I *must* be able to compile that
    code (i.e. know of all its dependencies and importantly, "dependency candidates
    that are not dependencies" - see below), otherwise, I have no way to
    derive the qualified name of a type.

    Here is an example:

    import comx.*;
    import comy.*;

    public class X {
    {
    // what exactly is Type?
    Type t;
    }

    // This is where it is worse, I cannot
    // determine how to call this method.
    // All I know is it accepts either comx.Type or comy.Type.
    // I cannot after all, derive all types of a given package.
    // My best guess is the same as my worst guess - infinity.
    public void method(Type t) {

    }
    }

    A final reason is that an introduction of a type into a package can cause
    a build failure. This is behaviour that is certainly undesirable. This is
    why I need to know build time dependencies and "dependency candidates
    that are not dependencies" if wildcard imports are used. Quite
    unreasonable given the near infinite possibilities.


    --
    Tony Morris
    http://tmorris.net/
     
    Tony Morris, Jul 18, 2006
    #11
  12. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Ingo R. Homann schreef:
    > Hi,
    >
    > Larry Barowski wrote:
    >>> I want to know why we have to remove those unused Import, use
    >>> java.util.ArrayList, don't use java.util.*, why we have to do this.
    >>> just for good code style ? or ....

    >>
    >>
    >> Using package imports can cause hidden problems. When
    >> you upgrade Java, or some other library, there may be
    >> new classes. The worst case is that you have a class with
    >> the same name as one of these, that has all the methods
    >> you use, and that does almost the same thing or is rarely
    >> used and rarely tested. So your project will compile, but
    >> will break at runtime in rare circumstances. ...A
    >> more common case is that a new class with the same
    >> name as one you are using is introduced, but you are
    >> using methods it does not have, or it breaks in an
    >> immediate and obvious way at runtime.

    >
    > Eh... just a second...:
    >
    > Joey asked for *unused* imports. If they are unused, the problems you
    > mention cannot occur!


    It can happen that you are referencing some package internal class, that
    suddenly is now imported from some other package, thus the other one is
    used etc.

    H.

    - --
    Hendrik Maryns

    ==================
    http://aouw.org
    Ask smart questions, get good answers:
    http://www.catb.org/~esr/faqs/smart-questions.html
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (GNU/Linux)

    iD8DBQFEvME6e+7xMGD3itQRAlxsAJ4gzAfoqS2TGLnrrpjp1ttcp6N1AgCfaa9w
    Tb35C/St3QSu+hKEdTHknuM=
    =j88y
    -----END PGP SIGNATURE-----
     
    Hendrik Maryns, Jul 18, 2006
    #12
  13. Hi,

    Hendrik Maryns wrote:
    >>Joey asked for *unused* imports. If they are unused, the problems you
    >>mention cannot occur!

    >
    > It can happen that you are referencing some package internal class, that
    > suddenly is now imported from some other package, thus the other one is
    > used etc.


    Joey asked for *unused* imports. Again: How do you think that problem
    can occur, if it is *un*used?

    Ciao,
    Ingo
     
    Ingo R. Homann, Jul 18, 2006
    #13
  14. Ingo R. Homann wrote:
    > Hi,
    >
    > Larry Barowski wrote:
    >>> I want to know why we have to remove those unused Import, use
    >>> java.util.ArrayList, don't use java.util.*, why we have to do this.
    >>> just for good code style ? or ....

    >>
    >>
    >> Using package imports can cause hidden problems. When
    >> you upgrade Java, or some other library, there may be
    >> new classes. The worst case is that you have a class with
    >> the same name as one of these, that has all the methods
    >> you use, and that does almost the same thing or is rarely
    >> used and rarely tested. So your project will compile, but
    >> will break at runtime in rare circumstances. ...A
    >> more common case is that a new class with the same
    >> name as one you are using is introduced, but you are
    >> using methods it does not have, or it breaks in an
    >> immediate and obvious way at runtime.

    >
    > Eh... just a second...:
    >
    > Joey asked for *unused* imports. If they are unused, the problems you
    > mention cannot occur!


    Unused imports, are, I think, safe from that problem. It is real for
    on-demand imports.

    Suppose, before JDK 1.2, a program were using both java.util.Vector and
    java.awt.List. References to "List" would have compiled with the
    on-demand imports:

    import java.awt.*;
    import java.util.*;

    "List" would have become ambiguous when the interface java.util.List was
    added in JDK 1.2.

    Patricia
     
    Patricia Shanahan, Jul 18, 2006
    #14
  15. -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA1

    Ingo R. Homann schreef:
    > Hi,
    >
    > Hendrik Maryns wrote:
    >>> Joey asked for *unused* imports. If they are unused, the problems you
    >>> mention cannot occur!

    >>
    >> It can happen that you are referencing some package internal class, that
    >> suddenly is now imported from some other package, thus the other one is
    >> used etc.

    >
    > Joey asked for *unused* imports. Again: How do you think that problem
    > can occur, if it is *un*used?


    import some.obscure.package.*

    Integer ref = new Integer(5);

    Now imagine the new release of some.obscure.package suddenly contains a
    class Integer which, coincidentally, has a constructor which has an int
    argument, and where all other operations that are used on ref are
    implemented as well, but behaves different as java.lang.Integer as that
    it is mutable or whatever.

    H.

    - --
    Hendrik Maryns

    ==================
    http://aouw.org
    Ask smart questions, get good answers:
    http://www.catb.org/~esr/faqs/smart-questions.html
    -----BEGIN PGP SIGNATURE-----
    Version: GnuPG v1.4.2 (GNU/Linux)

    iD8DBQFEvPXGe+7xMGD3itQRAnRQAJ4wgdiMEPnFiRDLtc2yqssEeZimnACfQXOM
    RsWx3XRRkJW0wj2I0ypISOQ=
    =fUy/
    -----END PGP SIGNATURE-----
     
    Hendrik Maryns, Jul 18, 2006
    #15
  16. "Ingo R. Homann" <> wrote in message
    news:44bc8e25$0$26257$-online.net...
    > Eh... just a second...:
    >
    > Joey asked for *unused* imports. If they are unused, the problems you
    > mention cannot occur!


    Read the post, not just the title.
    "I want to know why we have to remove those unused Import, use
    java.util.ArrayList, don't use java.util.*, why we have to do this.
    just for good code style ? or ....".

    What do you think "don't use java.util.*" means?
     
    Larry Barowski, Jul 18, 2006
    #16
  17. Joey

    jmcgill Guest

    Ingo R. Homann wrote:

    > Joey asked for *unused* imports. Again: How do you think that problem
    > can occur, if it is *un*used?



    It is not meant to be used, but it can lead to degenerate binding where
    it is unintentionally used. Happens fairly often, in cases where a
    class name is common among libraries. XML binding frameworks come to
    mind as a repeat offender for me.
     
    jmcgill, Jul 18, 2006
    #17
  18. Hi,

    Hendrik Maryns wrote:
    > import some.obscure.package.*
    >
    > Integer ref = new Integer(5);
    >
    > Now imagine the new release of some.obscure.package suddenly contains a
    > class Integer which, coincidentally, has a constructor which has an int
    > argument, and where all other operations that are used on ref are
    > implemented as well, but behaves different as java.lang.Integer as that
    > it is mutable or whatever.


    OK, I was too much stick to the subject. I did not realize that you were
    talking about wildcard-imports!

    Ciao,
    Ingo
     
    Ingo R. Homann, Jul 19, 2006
    #18
  19. Hi Larry,

    Larry Barowski wrote:
    > Read the post, not just the title.


    Of course you are right, that's a good idea. :)

    I concentrated too much on the title. (Especially because my English is
    not the best, it is a good idea to really concentrate while reading...)

    Ciao,
    Ingo
     
    Ingo R. Homann, Jul 19, 2006
    #19
    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. Replies:
    3
    Views:
    919
    Thomas Weidenfeller
    Aug 22, 2006
  2. Mr. SweatyFinger
    Replies:
    2
    Views:
    2,071
    Smokey Grindel
    Dec 2, 2006
  3. Replies:
    32
    Views:
    1,704
    dgutson
    Sep 15, 2012
  4. Scott M.

    Remove Unused References?

    Scott M., Sep 13, 2008, in forum: ASP .Net
    Replies:
    0
    Views:
    437
    Scott M.
    Sep 13, 2008
  5. ton
    Replies:
    5
    Views:
    1,418
    Scott M.
    Feb 2, 2010
Loading...

Share This Page