specifying import, is there a difference in memory usage?

[Russell]

Does it matter if you say

import java.awt.*

or

import java.awt.<the exact file you want>

I am used to specifying the wild card and was wondering if I am using
more memory at run time than I need to or if it doesn't matter as the
compiler takes care of it. Any other reasons for using ones way over
the other?

Thanks in advance,
Russell

 

[dhiraj.peechara]

It is just a good practise to explictly metion import for every class.
The compiler will replace import.awt.* with only classes it needs.

 

[Ryan Stewart]

It is just a good practise to explictly metion import for every class.

[...]
Please provide a reference to support this claim.

 

[moongate]

It is just a good practise to explictly metion import for every

class.
[...]
Please provide a reference to support this claim.

Uhm... I think both the OP's question and the reply are based on a
misconception of the meaning of import.

import has absolutely nothing to do with memory usage. When you import
java.awt.Applet, the *only* consequence of this import is that you can
now use the Applet identifier as in:

Applet myapplet;

instead of having to explicitly write

java.awt.Applet myapplet;

imports are just a mechanism for namespace management; specifically,
they have no relation whatsoever with linking and no similarities with
mechanisms such as #include (C). You can easily test this by yourself:

write a simple program with no imports, and compile. Then modify the
program throwing in as many (unused) import clauses as you like, and
recompile. You will see that the generated ".class" files are in fact
identical in size (and content; you could manage to check this using a
checksum tool such as "sum" under Unix or a "diff" command).

MC

 

[Ryan Stewart]

It is just a good practise to explictly metion import for every

class.
[...]
Please provide a reference to support this claim.

Uhm... I think both the OP's question and the reply are based on a
misconception of the meaning of import.

[...]
I think you might want to read the reply and my reply again. I'm not asking
anything about memory usage or even anything to do with running code.
dhirag.peechara made a statement about style, and I'm asking him to provide a
reference to back up his claim.

 

[John C. Bollinger]

It is just a good practise to explictly metion import for every class.

[...]
Please provide a reference to support this claim.

It's discussed here from time to time.

Advantages of importing whole packages: quicker to write and maintain.

Advantages of importing specific classes: explicitly specifies the
external classes used in summary form; reduces the likelihood of
unqualified name collisions.

It seems (subjectively, to me) to be the prevailing opinion that
providing explicit class imports is the preferable approach. The
maintenance burden of this approach is greatly reduced by existing tools
that help manage imports in your source files; one such is built into
Eclipse, and I'm sure some other Java IDEs must have them as well.


John Bollinger
(e-mail address removed)

 

[moongate]

I think you might want to read the reply and my reply again. I'm not asking
anything about memory usage or even anything to do with running code.

dhirag.peechara made a statement about style, and I'm asking him to provide a
reference to back up his claim.

Ooops. That happens to be my 2nd false step in a very brief time on
this ng. Beg forgiveness. Anyway, if you will let me in the discussion
all the same:

I think the claim that it *is* good practice to only mention the
classes you need in import is obviously right. import java.awt.* makes
a whole lot of class names available in your name space, thus making
name-clashes more likely, while import java.awt.Applet only introduces
one name, which does less harm.

That it is *only* good practice, (I think,) means that there is no
difference between the two approaches apart from that mentioned above.
Since any other difference that may occur to my mind has to do with
compiled code, and since compiled code is identical (which you didn't
question, in fact), I would say that
dhirag is true. I don't think any "reference" is needed to support both
claims, since they border on (are?) obvious.
So, am I missing... what?
MC

 

[Chris Uppal]

It's discussed here from time to time.

Advantages of importing whole packages: quicker to write and maintain.

Personally, for packages that are "central" to a task, or which are so
well-known that "everybody" knows about them (e.g. java.lang.util) I prefer to
use just a blanket include <package>.*; This is /not/ (only) in order to save
me typing, but as a promise to the reader that I'm not using any unexpected
classnames.

I also think that the practise of using import <classname>; is a half-way house
between the complete clarity that would result from giving a fully-qualified
classname at the point of use, and the relative convenience of using a wildcard
import. It is not clear to me that the halfway-house is actually a better
compromise than either of the extremes, indeed for many purposes I like to use
a fully qualified classname.

-- chris

 

[Andrew Thompson]

while import java.awt.Applet only introduces one name..

Do you perhaps mean java.applet.Applet? ;-)

 

[Tor Iver Wilhelmsen]

There is no difference in memory usage. Importing class names is for
the benefit of the compiler and programmer: In the resulting class
file, all necessary class names will be fully qualified, and no names
of "unused" classes will be there.

(For completeness' sake, the same of course holds if you use no import
but use the fully qualified name in the source.)

 

[Chris Riesbeck]

Personally, for packages that are "central" to a task, or which are so
well-known that "everybody" knows about them (e.g. java.lang.util) I prefer to
use just a blanket include <package>.*; This is /not/ (only) in order to save
me typing, but as a promise to the reader that I'm not using any unexpected
classnames.

I didn't follow this part. What do you mean by using an unexpected classname?

I also think that the practise of using import <classname>; is a half-way house
between the complete clarity that would result from giving a fully-qualified
classname at the point of use, and the relative convenience of using a wildcard
import. It is not clear to me that the halfway-house is actually a better
compromise than either of the extremes, indeed for many purposes I like to use
a fully qualified classname.

Speaking personally, based on code I've had to maintain or adapt,
my preferences are, in order:

- import fully qualified class name
- import package.*
- fully qualified class name at point of use

The 3rd approach, for me, leads to a lot of code clutter and
unexpected library dependencies -- com.defunct-company.what?

The 1st approach tells me not only what's being used, but
often the "vintage" or sophistication of the code, e.g.,
if I see Vector and not ArrayList or Collection etc.

 

[Chris Uppal]

I didn't follow this part. What do you mean by using an unexpected
classname?

Well, say that I'm going to be using stuff from java.util, if I put import
java.util.* at the head of the file then I am assuring the reader that if they
see, say, HashMap in the code then they can assume that it's the same HashMap
as they know and love, not another class with the same name (my own
implementation, perhaps). You'll note that unless such classname clashes /do/
occur, there is little point to the Java package mechanism at all (not /no/
point). Conversely, if I do want to use my own flavour of HashMap, then I'll
be forced to use the fully qualified name at the point of use, thus alerting
the reader to the fact that there's something going on that they may not have
expected if I'd used specific imports for all the referenced classes (since
then the name at point-of-use would be "HashMap" and they'd have to refer to
the beginning of the file to see that it wasn't the usual HashMap -- but then
how are they supposed to know that they ought to check ?)

Note that this only "works" with fairly small packages that can be expected to
be well known to the reader -- I wouldn't include the Swing/AWT stuff in that
category...

-- chris