Why we have to remove unused Import

java-programmer, Why we have to remove unused Import 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.

java-programmer >> Why we have to remove unused Import
"Joey" <email***@***.com> wrote in message
news:email***@***.com...
> 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.

java-programmer >> Why we have to remove unused Import Joey wrote:
> 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

java-programmer >> Why we have to remove unused Import Patricia Shanahan wrote:
> Joey wrote:
>> 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

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

java-programmer >> Why we have to remove unused Import Thanks everyone, I also want to know does unused import cause memory
problem, I mean, it will use more memory?

java-programmer >> Why we have to remove unused Import email***@***.com wrote:

> 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

java-programmer >> Why we have to remove unused Import IchBin wrote:

> 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

java-programmer >> Why we have to remove unused Import Hi,

email***@***.com wrote:
> 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 ;-)

java-programmer >> Why we have to remove unused Import Hi,

Larry Barowski wrote:
>>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. ...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

java-programmer >> Why we have to remove unused Import email***@***.com wrote:
> 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

java-programmer >> Why we have to remove unused Import On Mon, 17 Jul 2006 18:46:09 -0700, Joey wrote:

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

--
Tony Morris
http://tmorris.net/

java-programmer >> Why we have to remove unused Import -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ingo R. Homann schreef:
> Hi,
>
> Larry Barowski wrote:
>>> 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. ...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!

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

java-programmer >> Why we have to remove unused Import Hi,

Hendrik Maryns wrote:
>>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.

Joey asked for *unused* imports. Again: How do you think that problem
can occur, if it is *un*used?

Ciao,
Ingo

java-programmer >> Why we have to remove unused Import Ingo R. Homann wrote:
> Hi,
>
> Larry Barowski wrote:
>>> 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. ...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!

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

java-programmer >> Why we have to remove unused Import -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ingo R. Homann schreef:
> Hi,
>
> Hendrik Maryns wrote:
>>> 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.
>
> 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-----

java-programmer >> Why we have to remove unused Import
"Ingo R. Homann" <email***@***.com> wrote in message
news:44bc8e25$0$26257$email***@***.com...
> 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?

java-programmer >> Why we have to remove unused Import Ingo R. Homann wrote:

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

java-programmer >> Why we have to remove unused Import Hi,

Hendrik Maryns wrote:
> 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

java-programmer >> Why we have to remove unused Import Hi Larry,

Larry Barowski wrote:
> 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