java package import, effect on performance?

[asrahma1111]

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.

 

[=?ISO-8859-1?Q?Daniel_Sj=F6blom?=]

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.

 

[VisionSet]

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.

 

[Karthik]

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.

 

[Tony Morris]

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

 

[Roedy Green]

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

 

[Andrew Thompson]

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.

 

[Roedy Green]

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 ?

 

[Andrew Thompson]

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.

 

[Dave Monroe]

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.

 

[Glenn]

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

 

[Chris Smith]

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