to use import java.lang.* or import java.lang.Math or none at all?

Discussion in 'Java' started by JPractitioner, Feb 20, 2006.

  1. Hi guys,
    i knew that by default all java.lang classes will be imported by the
    compiler during compilation. but, to make it easier for the computer,
    should i specify which class i really will be using? does this action
    will boost the performance during compilation and runtime or not a
    matter at all?

    the answer to this post will definitely affect my programming style in
    the future when i'm considering "to import or not to import"...
    hmm,,,


    thanks in advance.
     
    JPractitioner, Feb 20, 2006
    #1
    1. Advertising

  2. JPractitioner

    Chris Uppal Guest

    JPractitioner wrote:

    > i knew that by default all java.lang classes will be imported by the
    > compiler during compilation. but, to make it easier for the computer,
    > should i specify which class i really will be using? does this action
    > will boost the performance during compilation and runtime or not a
    > matter at all?


    Whether and how you import classes has exactly zero effect at runtime. Imports
    (with or without wildcards) are only a kind of abbreviation provided by the
    compiler to save us the effort of typing in fully-qualified type names every
    time.

    In theory explicit importing should make compilation faster -- by a very tiny
    amount. I've never heard anyone claim that they've even managed to measure a
    difference let alone found a case where it made a practical difference.

    So the question comes down to how to write your code for maximum clarity. One
    school of thought asserts that you should always import each class explicitly
    (rather than by a wildcard). There's a fair consensus on that point -- with
    which I disagree. For some reason, the advocates of that point of view seem to
    exclude classes in the java.lang package. I agree entirely that it would be
    counter-productive to be explicit about importing those classes -- I just
    extend the logic to other well-known packages where they fail to do so ;-)

    Still, that /is/ the consensus, so -- unless you prize "best practice" over
    "common practice" (and there are arguments to be made for both positions) --
    you won't go /too/ far wrong by falling in with the crowd, and your life may be
    a little easier.

    -- chris
     
    Chris Uppal, Feb 20, 2006
    #2
    1. Advertising

  3. Re: to use import java.lang.* or import java.lang.Math or none atall?

    JPractitioner wrote:
    > i knew that by default all java.lang classes will be imported by the
    > compiler during compilation. but, to make it easier for the computer,
    > should i specify which class i really will be using?


    No.

    > does this action
    > will boost the performance during compilation and runtime or not a
    > matter at all?


    No.

    > the answer to this post will definitely affect my programming style in
    > the future when i'm considering "to import or not to import"...


    Are you that easy to convince? I have that lovely bridge on sale ... ;-)

    /Thomas
    --
    The comp.lang.java.gui FAQ:
    ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
    http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/
     
    Thomas Weidenfeller, Feb 20, 2006
    #3
  4. Re: to use import java.lang.* or import java.lang.Math or none atall?

    Chris Uppal wrote:
    > Still, that /is/ the consensus, so -- unless you prize "best practice" over
    > "common practice" (and there are arguments to be made for both positions) --
    > you won't go /too/ far wrong by falling in with the crowd, and your life may be
    > a little easier.


    I only see it as "consensus" among people using certain IDE's who happen
    to shout loudest and among some book authors. The later often of the
    type where, by judging them by their books, they have never written any
    program larger than Hello World.

    /Thomas

    --
    The comp.lang.java.gui FAQ:
    ftp://ftp.cs.uu.nl/pub/NEWS.ANSWERS/computer-lang/java/gui/faq
    http://www.uni-giessen.de/faq/archiv/computer-lang.java.gui.faq/
     
    Thomas Weidenfeller, Feb 20, 2006
    #4
  5. JPractitioner

    Guest

    It's up to you really. Different people have different styles. As far
    as I know, importing in groups won't slow it down or make it larger but
    it does make it less obvious to anyone else who reads your code as to
    exactly which classes the methods you've used have come from.
     
    , Feb 20, 2006
    #5
  6. Thanks all for the replies..
    since there will be no affect on performance during runtime,
    i'll be hapier using the wildcards..
    but the idea of making it more obvious to other peoples(clarity
    purposes) is good
    hehe, thomas, actually it depends on how satisfying the answers i'm
    getting..
    sorry to not mentioning that :D
    by the way, how much is the bridge?

    Thanks again all.
    Cheers.
     
    JPractitioner, Feb 20, 2006
    #6
  7. Re: to use import java.lang.* or import java.lang.Math or none atall?

    Thomas Weidenfeller wrote:
    > Chris Uppal wrote:
    >
    >> Still, that /is/ the consensus, so -- unless you prize "best practice"
    >> over
    >> "common practice" (and there are arguments to be made for both
    >> positions) -- you won't go /too/ far wrong by falling in with the
    >> crowd, and your life may be
    >> a little easier.

    >
    >
    > I only see it as "consensus" among people using certain IDE's who happen
    > to shout loudest and among some book authors. The later often of the
    > type where, by judging them by their books, they have never written any
    > program larger than Hello World.


    And among people who do not like to risk having their code fail to
    compile when third parties add classes to their packages.

    Ray

    --
    This signature intentionally left blank.
     
    Raymond DeCampo, Feb 20, 2006
    #7
  8. JPractitioner

    Chris Uppal Guest

    Thomas Weidenfeller wrote:

    > > Still, that /is/ the consensus, so -- unless you prize "best practice"
    > > over "common practice" (and there are arguments to be made for both
    > > positions) -- you won't go /too/ far wrong by falling in with the
    > > crowd, and your life may be a little easier.

    >
    > I only see it as "consensus" among people using certain IDE's who happen
    > to shout loudest and among some book authors.


    <grin>

    There is something in what you say ;-)

    -- chris
     
    Chris Uppal, Feb 20, 2006
    #8
  9. Re: to use import java.lang.* or import java.lang.Math or none atall?

    Thomas Weidenfeller wrote:
    > JPractitioner wrote:
    >> does this action
    >> will boost the performance during compilation and runtime or not a
    >> matter at all?

    >
    > No.


    I know you are saying no. But to expand the question a bit.
    Does this affect in any way how fast the jvm starts up? considering the
    long list of classes loaded when the jvm start. I would logically think
    that reducing the number of classes read in that list would at least
    affect the startup time. Especially when using lots of third party
    libraries, which might be quite large. Further on the question can be
    expanded to adding large jars in the classpath, how does that affect
    both startup time and other aspects.

    Is the answer still no? I know it has to touch the file/class anyway to
    be able determine if its something to use, but does that mean no extra
    cost after that?.

    /tom
     
    tom fredriksen, Feb 20, 2006
    #9
  10. yeah, i am using third party jars as well, good one tom :)
     
    JPractitioner, Feb 20, 2006
    #10
  11. JPractitioner

    Daniel Dyer Guest

    On Mon, 20 Feb 2006 17:26:52 -0000, tom fredriksen <> wrote:

    > Thomas Weidenfeller wrote:
    >> JPractitioner wrote:
    >>> does this action
    >>> will boost the performance during compilation and runtime or not a
    >>> matter at all?

    >> No.

    >
    > I know you are saying no. But to expand the question a bit.
    > Does this affect in any way how fast the jvm starts up? considering the
    > long list of classes loaded when the jvm start. I would logically think
    > that reducing the number of classes read in that list would at least
    > affect the startup time. Especially when using lots of third party
    > libraries, which might be quite large.


    The import statement only has an impact at compile time. The generated
    class file will be the same whether you use wildcard imports or specify
    each class individually. The class file will have no reference to classes
    that you have imported but not actually used.

    Dan.

    --
    Daniel Dyer
    http://www.dandyer.co.uk
     
    Daniel Dyer, Feb 20, 2006
    #11
  12. JPractitioner

    Chris Uppal Guest

    tom fredriksen wrote:

    >[...] to expand the question a bit.
    > Does this affect in any way how fast the jvm starts up?


    Depends whether you are asking about import statements or the classes
    themselves.

    If you are asking about imports then they have /no/ effect on /anything/ at
    runtime. Zero. Simply because no information about imports is retained in
    ..class files -- all class references are resolved into fully-qualified names by
    the compiler. That applies to explicit imports of specific classes, to
    wildcard imports, and to the implicit import of java.lang.*.


    > considering the
    > long list of classes loaded when the jvm start. I would logically think
    > that reducing the number of classes read in that list would at least
    > affect the startup time.


    OTOH, the more classes that have to be loaded, the longer it will take. But
    it's only classes that are actually used or referred to (e.g. as the type of a
    method's parameter) that have to be touched at all (imports, as I said above,
    don't matter). The JVM is allowed a fair amount of leeway in postponing these
    activities for as long as it decently can, but -- obviously -- the more classes
    are directly involved in, or needed by, your app's startup, the longer that
    startup will take.

    > Especially when using lots of third party
    > libraries, which might be quite large. Further on the question can be
    > expanded to adding large jars in the classpath, how does that affect
    > both startup time and other aspects.


    The number of classes on the classpath can certainly have an effect on the time
    it takes to locate a class. Imagine a classpath with a couple of hundred
    million JAR files for instance -- it'd be kinda slow, and might not fit in
    memory at all ;-) Also the bigger the JAR the more memory it takes to store
    the table of contents. So lots of large JARs might have a detectable effect.
    But note that any sensible classloader implementation will build some sort of
    fast lookup (hash table, or whatever) so the chances are that actually locating
    classes will not be a significant factor in the time it takes to load them.

    Some of the performance tweaking that has gone on between 1.4, 1.5, and what
    (little) I know of 1.6, has revolved around optimising the way that classes are
    loaded at startup, and how best to balance speed with memory requirements for
    loading JARs.

    -- chris
     
    Chris Uppal, Feb 20, 2006
    #12
  13. JPractitioner

    Roedy Green Guest

    On Mon, 20 Feb 2006 13:40:14 +0100, Thomas Weidenfeller
    <> wrote, quoted or indirectly quoted someone
    who said :

    >I only see it as "consensus" among people using certain IDE's who happen
    >to shout loudest and among some book authors. The later often of the
    >type where, by judging them by their books, they have never written any
    >program larger than Hello World.


    With Eclipse or IntelliJ to deal with imports, I am very glad of it to
    maintain and explicit list with no deadwood. This is a great help in
    coming back to code cold. A quick look at at the imports narrows down
    immediately what sort of things a class COULD be up to.

    While coding I use lots of *s, and let Eclipse tidy them up later. No
    point in me manually typing out all the names. Earlier, in SlickEdit,
    I had a macro to dump the kitchen sink in there, which I later tidied
    out with a utility.

    I have written quito a bit on how I think you should do this. See
    http://mindprod.com/jgloss/import.html
    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Feb 24, 2006
    #13
  14. JPractitioner

    Roedy Green Guest

    On Mon, 20 Feb 2006 18:26:52 +0100, tom fredriksen <>
    wrote, quoted or indirectly quoted someone who said :

    >
    >I know you are saying no. But to expand the question a bit.
    >Does this affect in any way how fast the jvm starts up?


    You missed the point. The import list is NOT a list of classes to
    load. It is list of to help expand short names in the code to fully
    qualified ones. The only classes that get loaded are the ones you
    actually use.

    See http://mindprod.com/jgloss/import.html

    --
    Canadian Mind Products, Roedy Green.
    http://mindprod.com Java custom programming, consulting and coaching.
     
    Roedy Green, Feb 24, 2006
    #14
    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. VK
    Replies:
    15
    Views:
    1,286
    Dr J R Stockton
    May 2, 2010
  2. length power
    Replies:
    2
    Views:
    109
    Rustom Mody
    Apr 10, 2014
  3. Skip Montanaro
    Replies:
    0
    Views:
    73
    Skip Montanaro
    Apr 10, 2014
  4. Johannes Schneider

    Re: why i have the output of [None, None, None]

    Johannes Schneider, Apr 10, 2014, in forum: Python
    Replies:
    0
    Views:
    63
    Johannes Schneider
    Apr 10, 2014
  5. Terry Reedy
    Replies:
    0
    Views:
    72
    Terry Reedy
    Apr 10, 2014
Loading...

Share This Page