Why we have to remove unused Import

J

Joey

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.
 
L

Larry Barowski

Joey said:
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.
 
P

Patricia Shanahan

Joey said:
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
 
I

IchBin

Patricia said:
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-)
 
H

huazonglin

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

Chris Uppal

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
 
C

Chris Uppal

IchBin said:
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
 
I

Ingo R. Homann

Hi,

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 ;-)
 
I

Ingo R. Homann

Hi,

Larry said:
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
 
P

Patricia Shanahan

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
 
T

Tony Morris

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.
 
H

Hendrik Maryns

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ingo R. Homann schreef:
Hi,



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-----
 
I

Ingo R. Homann

Hi,

Hendrik said:
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
 
P

Patricia Shanahan

Ingo said:
Hi,



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
 
H

Hendrik Maryns

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ingo R. Homann schreef:
Hi,



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-----
 
L

Larry Barowski

Ingo R. Homann said:
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?
 
J

jmcgill

Ingo said:
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.
 
I

Ingo R. Homann

Hi,

Hendrik said:
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
 
I

Ingo R. Homann

Hi Larry,

Larry said:
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
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,756
Messages
2,569,535
Members
45,008
Latest member
obedient dusk

Latest Threads

Top