cost of unused import statement

[Jeff]

I just switched to Eclipse IDE which has a rigorous code checker. It warned
me that I have some unused import statements. I fixed them, but I'm curious
whether an import statement has any performance impact. So I turn to the
fount of Java wisdom, comp.lang, java. programmer. Does an import statement
have any performance impact?

 

[VisionSet]

I just switched to Eclipse IDE which has a rigorous code checker. It warned
me that I have some unused import statements. I fixed them, but I'm curious
whether an import statement has any performance impact. So I turn to the
fount of Java wisdom, comp.lang, java. programmer. Does an import statement
have any performance impact?

None whatsoever. It is purely a name space mechanism.

 

[andreas]

I have some unused import statements. I fixed them, but I'm

curious

None whatsoever. It is purely a name space mechanism.

you should import only what you need though for readability.
imagine you have a class List. then you might want to know
what package this list implementation is from.
i therefore never use the * in the import statement but import
every single class (which may result in pretty large import blocks).

andreas

 

[Thomas Fritsch]

I just switched to Eclipse IDE which has a rigorous code checker. It warned
me that I have some unused import statements. I fixed them, but I'm curious
whether an import statement has any performance impact. So I turn to the
fount of Java wisdom, comp.lang, java. programmer. Does an import statement
have any performance impact?

No performance impact, but a risk of semantic impact. For example:

package my.package;
import java.lang.reflect.*;
import java.sql.*;

class Array { }
....
Array a; // Array from which of the 3 packages is meant ?

 

[VisionSet]

you should import only what you need though for readability.
imagine you have a class List. then you might want to know
what package this list implementation is from.
i therefore never use the * in the import statement but import
every single class (which may result in pretty large import blocks).

Like I say, it's a name space mechanism.

If you do .* then you open yourself up to previous namespace pollution sins.

awt.List & util.List of which are my personal bugbears.

Importing both explicitly does not help you determine which one a statement
is from and then you are forced to give fully qualified class names to
achieve your goal.

At some point in solving name space pollution you have to strike a
compromise between verbosity and clarity. I don't hold that they are
necessarily the same thing.

 

[Brusque]

I just switched to Eclipse IDE which has a rigorous code checker. It warned
me that I have some unused import statements. I fixed them, but I'm curious
whether an import statement has any performance impact. So I turn to the
fount of Java wisdom, comp.lang, java. programmer. Does an import statement
have any performance impact?

I seem to recall reading somewhere that compilation might be faster if your
imports are tidy, but I doubt it would be noticeable. Runtime performance
however is unchanged. The bytecode generated will be exactly the same no
matter what imports your source contains (assuming no compile errors of
course)

 

[Thomas G. Marshall]

andreas coughed up:

I have some unused import statements. I fixed them, but I'm

you should import only what you need though for readability.
imagine you have a class List. then you might want to know
what package this list implementation is from.
i therefore never use the * in the import statement but import
every single class (which may result in pretty large import blocks).

andreas

CORRECT.

IMHO, the most important ( ) use for import statements is to serve as
/documentation of precisely which classes you are using/. Repeat this
statement as needed.

And .* also raises the inevitable name space collisions, which are a
nuisance.

 

[Chris Smith]

No performance impact, but a risk of semantic impact. For example:

package my.package;
import java.lang.reflect.*;
import java.sql.*;

class Array { }
...
Array a; // Array from which of the 3 packages is meant ?

If anyone cares, that's a reference to my.package.Array. You can find
the nitty-gritty at JLS section 6.5.5.1.

The fact that many people will probably need to look this up reinforces
the recommendation against relying on it, of course.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Tony Morris]

Yes.
It will impact compile-time performance.
It will also impact the performance of code maintainers since readability is
reduced a little.
Runtime performance is not impacted.

http://www.xdweb.net/~dibblego/java/faq/answers.html#q36

 

[P.Hill]

If anyone cares, that's a reference to my.package.Array. You can find
the nitty-gritty at JLS section 6.5.5.1.

Assuming there is an Array in my.package, but if there isn't one then
you'd better find one and only one in one of the "type-import-on-demand"
declarations (the .* imports) or a compile-time error will occur.

-Paul

 

[Chris Smith]

Assuming there is an Array in my.package, but if there isn't one then
you'd better find one and only one in one of the "type-import-on-demand"
declarations (the .* imports) or a compile-time error will occur.

I misread the above, and thought that the reference was from inside the
declaration of my.package.Array. Nevertheless, they still appear to be
contained in the same compilation unit, so the class does exist. If
thery weren't in the same compilation unit, then the reference would
still compile to my.package.Array, so long as that class existed in the
package. If not, then you'd get a compilation error, since
java.lang.reflect.Array and java.sql.Array both exist.

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

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation

 

[Mike Schilling]

andreas coughed up:

CORRECT.

IMHO, the most important ( ) use for import statements is to serve as
/documentation of precisely which classes you are using/. Repeat this
statement as needed.

And .* also raises the inevitable name space collisions, which are a
nuisance.

One more point: the import declarations should be neatly arranged (I prefer
by package,and alphabetical within that), since they're useless if you can't
find the one you're looking for.

It's interesting to me that Thomas and Andreas's opinion is common among
Java programmers (I share it, for instance) , but unknown among C#
programmers. C# allows:

using Namespace; // like Java import Namespace.*

and

using Name = Namespace.ClassName;
// like Java single class import , with optional aliasing

But no one uses the latter: no examples, no tutorials, nada. When I asked
on one of their newsgroups why not, most people had never heard of it and a
few told me it was illegal.

 

[Thomas G. Marshall]

Mike Schilling coughed up:

"Thomas G. Marshall"


One more point: the import declarations should be neatly arranged (I
prefer by package,and alphabetical within that), since they're
useless if you can't find the one you're looking for.

It's interesting to me that Thomas and Andreas's opinion is common
among Java programmers (I share it, for instance) , but unknown among
C# programmers. C# allows:

using Namespace; // like Java import Namespace.*

and

using Name = Namespace.ClassName;
// like Java single class import , with optional aliasing

But no one uses the latter: no examples, no tutorials, nada. When I
asked on one of their newsgroups why not, most people had never heard
of it and a few told me it was illegal.

You have *GOT* to be kidding. How does C# resolve accidental collisions of
names deep within two names spaces, both used?

 

[Mike Schilling]

You have *GOT* to be kidding. How does C# resolve accidental collisions
of
names deep within two names spaces, both used?

In principle, it's nicer than Java, since the aliasing allows short names
for two classes that would otherwise conflict. In practice, they seem to
fully qualify anything that would conflict.