java package import, effect on performance?

Discussion in 'Java' started by asrahma1111, Apr 28, 2004.

  1. asrahma1111

    asrahma1111 Guest

    I'm writing up some coding conventions for our company, I think I
    might have read it a long time ago, and I see it in code out there all
    the time, but I'm not sure why. I'm guessing because it improves
    performance. Basically I'm asking whether this:

    import java.sql.Statement;
    import java.sql.ResultSet;
    import java.sql.Connection;
    import java.sql.SQLException;

    As opposed to this:

    import java.sql.*;

    improves performance? And if it does, why? Thanks, your feedback is
    much appreciated.
    asrahma1111, Apr 28, 2004
    #1
    1. Advertising

  2. asrahma1111 wrote:
    > I'm writing up some coding conventions for our company, I think I
    > might have read it a long time ago, and I see it in code out there all
    > the time, but I'm not sure why. I'm guessing because it improves
    > performance. Basically I'm asking whether this:
    >
    > import java.sql.Statement;
    > import java.sql.ResultSet;
    > import java.sql.Connection;
    > import java.sql.SQLException;
    >
    > As opposed to this:
    >
    > import java.sql.*;
    >
    > improves performance? And if it does, why? Thanks, your feedback is
    > much appreciated.


    It doesn't improve the runtime performance of the app, since in the
    bytecode all classes must be referenced by their full name anyway. It
    may *compile* faster because the compiler doesn't need to look up the
    individual full names of classes you might use from a huge package.
    Personally, I import every class separately, as it unambigiously states
    exactly what classes I'm using.
    --
    Daniel Sjöblom
    Remove _NOSPAM to reply by mail
    =?ISO-8859-1?Q?Daniel_Sj=F6blom?=, Apr 28, 2004
    #2
    1. Advertising

  3. asrahma1111

    VisionSet Guest

    "asrahma1111" <> wrote in message
    news:...
    > I'm writing up some coding conventions for our company, I think I
    > might have read it a long time ago, and I see it in code out there all
    > the time, but I'm not sure why. I'm guessing because it improves
    > performance. Basically I'm asking whether this:
    >
    > import java.sql.Statement;
    > import java.sql.ResultSet;
    > import java.sql.Connection;
    > import java.sql.SQLException;
    >
    > As opposed to this:
    >
    > import java.sql.*;
    >
    > improves performance? And if it does, why? Thanks, your feedback is
    > much appreciated.


    No, it makes no difference to performance it is merely a class resolution
    mechanism for the compiler. It makes your code tidier, and can help resolve
    conflicts like the sodding java.util.List v java.awt.List.

    --
    Mike W
    VisionSet, Apr 28, 2004
    #3
  4. asrahma1111

    Karthik Guest

    asrahma1111 wrote:

    > I'm writing up some coding conventions for our company, I think I
    > might have read it a long time ago, and I see it in code out there all
    > the time, but I'm not sure why. I'm guessing because it improves
    > performance. Basically I'm asking whether this:
    >
    > import java.sql.Statement;
    > import java.sql.ResultSet;
    > import java.sql.Connection;
    > import java.sql.SQLException;
    >
    > As opposed to this:
    >
    > import java.sql.*;
    >
    > improves performance? And if it does, why? Thanks, your feedback is
    > much appreciated.

    It does not make an iota of difference in terms of performance, because
    the class file binaries dont contain the info. at all.
    However as a good programming practice, it is always better to avoid
    the wildcard character, to avoid namespace pollution , so that it is
    clear for anyone who happen to read your program to know the classes
    that are imported.

    --
    Karthik
    Humans please 'removeme_' for my real email.
    Karthik, Apr 28, 2004
    #4
  5. asrahma1111

    Tony Morris Guest

    "asrahma1111" <> wrote in message
    news:...
    > I'm writing up some coding conventions for our company, I think I
    > might have read it a long time ago, and I see it in code out there all
    > the time, but I'm not sure why. I'm guessing because it improves
    > performance. Basically I'm asking whether this:
    >
    > import java.sql.Statement;
    > import java.sql.ResultSet;
    > import java.sql.Connection;
    > import java.sql.SQLException;
    >
    > As opposed to this:
    >
    > import java.sql.*;
    >
    > improves performance? And if it does, why? Thanks, your feedback is
    > much appreciated.


    A common misconception.
    Performance is improved at compile-time. The compiler can resolve your
    classes quicker. This does NOT affect runtime performance in any way (you
    can look at the bytecode and see that it is exactly the same if you like).

    I believe that fully qualifying imports is a good practice, but not to
    improve the speed at which the application compiles. It is a form of
    "encapsulation" (loosely speaking), since the intended function of a class
    is more easily determined by reading fully qualified imports, rather than
    wildcard imports.

    For example,

    import java.util.List;
    import java.util.ArrayList;

    class Queue
    {
    ...

    A reasonable assumption (that, of course, should be clarified) is that the
    class Queue keeps an internal List reference to an ArrayList - this could
    not be determined simply with "import java.util.*;". Of course, an
    assumption is made that all imports are actually used - my preferred
    development environment flags those that are unused, so a little bias in my
    opinion may be evident.

    --
    Tony Morris
    (BInfTech, Cert 3 I.T.)
    Software Engineer
    (2003 VTR1000F)
    Sun Certified Programmer for the Java 2 Platform (1.4)
    Sun Certified Developer for the Java 2 Platform
    Tony Morris, Apr 28, 2004
    #5
  6. asrahma1111

    Roedy Green Guest

    On 28 Apr 2004 12:41:57 -0700, (asrahma1111)
    wrote or quoted :

    >I'm writing up some coding conventions for our company, I think I
    >might have read it a long time ago, and I see it in code out there all
    >the time, but I'm not sure why. I'm guessing because it improves
    >performance. Basically I'm asking whether this:
    >
    >import java.sql.Statement;
    >import java.sql.ResultSet;
    >import java.sql.Connection;
    >import java.sql.SQLException;
    >
    >As opposed to this:
    >
    >import java.sql.*;


    both have their uses. During debug the second is better since you
    don't have to stop and keep adding classes.

    I use a standard set invoked by clicking an icon on my toolbar.

    import java.awt.*;
    import java.awt.event.*;
    import java.awt.image.*;
    import java.io.*;
    import java.net.*;
    import java.util.*;
    import java.util.zip.*;
    import javax.swing.*;
    import javax.swing.event.*;
    import javax.swing.tree.*;

    The first form is better for someone trying to understand the program.
    It outlines just what things the program could POSSIBLY do.

    I convert the first to the second with a bat file I run once
    everything is working.

    rem tidy imports
    java -jar E:\iscrub\import-scrubber-10.0.0.jar . -recurse

    rem redate files back the way they were.
    java com.mindprod.untouch.Untouch .

    Untouch redates files back that have not really changed.

    If I go back to debugging I just add a ton of generic imports, and let
    tidyi.bat sort it all out later.


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




    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Apr 29, 2004
    #6
  7. On Wed, 28 Apr 2004 14:32:11 -0700, Karthik wrote:

    > It does not make an iota of difference in terms of performance, because
    > the class file binaries dont contain the info. at all.


    Compile the two and you will find that
    the class sizes are different.

    --
    Andrew Thompson
    http://www.PhySci.org/ Open-source software suite
    http://www.PhySci.org/codes/ Web & IT Help
    http://www.1point1C.org/ Science & Technology
    Andrew Thompson, Apr 29, 2004
    #7
  8. asrahma1111

    Roedy Green Guest

    On Thu, 29 Apr 2004 04:09:39 GMT, Andrew Thompson
    <> wrote or quoted :

    >Compile the two and you will find that
    >the class sizes are different.


    Have you peeked at the class file to figure out why. That does not
    make sense. The only classes mentioned in a class file are the ones
    you use.

    Are you sure you got the same List both times ? :)

    --
    Canadian Mind Products, Roedy Green.
    Coaching, problem solving, economical contract programming.
    See http://mindprod.com/jgloss/jgloss.html for The Java Glossary.
    Roedy Green, Apr 29, 2004
    #8
  9. On Thu, 29 Apr 2004 05:04:30 GMT, Roedy Green wrote:

    > On Thu, 29 Apr 2004 04:09:39 GMT, Andrew Thompson

    ....
    >>Compile the two and you will find that
    >>the class sizes are different.


    I did and thought I saw they were!

    > Have you peeked at the class file to figure out why.


    No. (Slack of me, I know, but I
    jumped to a conclusion)

    >..That does not
    > make sense. The only classes mentioned in a class file are the ones
    > you use.


    Did a quick test that confirmed you,
    Karthik, Tony and Mike were completely
    correct.

    The class files were _exactly_ the
    same size. (Oops!) My bad.

    --
    Andrew Thompson
    http://www.PhySci.org/ Open-source software suite
    http://www.PhySci.org/codes/ Web & IT Help
    http://www.1point1C.org/ Science & Technology
    Andrew Thompson, Apr 29, 2004
    #9
  10. asrahma1111

    Dave Monroe Guest

    (asrahma1111) wrote in message news:<>...
    > I'm writing up some coding conventions for our company, I think I
    > might have read it a long time ago, and I see it in code out there all
    > the time, but I'm not sure why. I'm guessing because it improves
    > performance. Basically I'm asking whether this:
    >
    > import java.sql.Statement;
    > import java.sql.ResultSet;
    > import java.sql.Connection;
    > import java.sql.SQLException;
    >
    > As opposed to this:
    >
    > import java.sql.*;
    >
    > improves performance? And if it does, why? Thanks, your feedback is
    > much appreciated.


    Try using the -verbose switch on the 'java' command. That should reveal the secret.
    Dave Monroe, Apr 29, 2004
    #10
  11. asrahma1111

    Glenn Guest

    We require developers in our organization to explicitly list each
    import used, rather than use a wildcard. We've found that it makes
    things clearer and easier to understand during troubleshooting, since
    the person doing the troubleshooting may not have been on the original
    development team. We also require the removal of any unused imports
    for clarity's sake. :)


    - Glenn


    (asrahma1111) wrote in message news:<>...
    > I'm writing up some coding conventions for our company, I think I
    > might have read it a long time ago, and I see it in code out there all
    > the time, but I'm not sure why. I'm guessing because it improves
    > performance. Basically I'm asking whether this:
    >
    > import java.sql.Statement;
    > import java.sql.ResultSet;
    > import java.sql.Connection;
    > import java.sql.SQLException;
    >
    > As opposed to this:
    >
    > import java.sql.*;
    >
    > improves performance? And if it does, why? Thanks, your feedback is
    > much appreciated.
    Glenn, Apr 29, 2004
    #11
  12. asrahma1111

    Chris Smith Guest

    Glenn wrote:
    > We require developers in our organization to explicitly list each
    > import used, rather than use a wildcard. We've found that it makes
    > things clearer and easier to understand during troubleshooting, since
    > the person doing the troubleshooting may not have been on the original
    > development team. We also require the removal of any unused imports
    > for clarity's sake. :)


    Indeed.

    This really isn't even such a big deal, once you realize that if they
    are using Eclipse, all you're doing is requiring that they press the
    keys Ctrl-Shift-O if they have problems, and use Ctrl-Space to add
    imports rather than pre-typing imports at the top of the file. I find
    it easier to work that way anyway. I'm sure other IDEs have similar
    features.

    --
    www.designacourse.com
    The Easiest Way to Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, May 1, 2004
    #12
    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. Parvinder
    Replies:
    6
    Views:
    730
    Thomas G. Marshall
    Feb 27, 2005
  2. JPractitioner
    Replies:
    13
    Views:
    20,118
    Roedy Green
    Feb 24, 2006
  3. Pierre Rouleau
    Replies:
    4
    Views:
    770
    Pierre Rouleau
    Mar 7, 2004
  4. George P
    Replies:
    3
    Views:
    669
    Alex Martelli
    Sep 11, 2004
  5. Gabriel Rossetti
    Replies:
    1
    Views:
    472
    ryles
    Sep 20, 2009
Loading...

Share This Page