import class vs package?

[BNM]

I've been wondering if there is a difference in running or building of
jar file between specifying each class in the 'import' statement
versus specifying the package.

My gut instincts tell me that the compiler's have gotten smart enough
(like the C compilers which are extremely sophisticated these days)
that there would only be very minor differences if any between
specifying a class or the whole package.

Also, would this make a difference in JBuilder when it generates the
jar file?

This is an important question so please be certain of your answer!

Thanks!
Brett

 

[Miguel De Anda]

I've been wondering if there is a difference in running or building of
jar file between specifying each class in the 'import' statement
versus specifying the package.

My gut instincts tell me that the compiler's have gotten smart enough
(like the C compilers which are extremely sophisticated these days)
that there would only be very minor differences if any between
specifying a class or the whole package.

Also, would this make a difference in JBuilder when it generates the
jar file?

This is an important question so please be certain of your answer!

Thanks!
Brett

It depends. If you are just making a cheapy little app, then who cares,
import the entire package. If you are making a larger app, consider this:

import mypackage.*;
import java.util.*;

class T {
...
List t = new LinkedList();
...
}

Looks fine right, but what if somehow, a LinkedList class gets put into
mypackage.* ? I've never tried it, but it seems like there would be
problems.

But who would put a linked list class in your package? Well you, or somebody
else. A linked list class is pretty easy to avoid but there are tons of
other ones with names that you might want. There is no restriction that
keeps you from having a maypackage.LinkedList class, and the fact there is a
java.util.LinkedList should not be a reason to keep you from having one.

I guess a better example would be this:

import mypackage.vegetables.*;

....
Veggie v1 = new Bean();
Veggie v2 = new Lettuce();
....

But later one you import the java.beans.* package, this will cause
conflicts.

I try to import classes myself, but it gets quite annoying. I guess the best
solution is to use the full classname:

mypaackage.vegetables.Veggie v1 = mypaackage.vegetables.Bean();

But then that can cause other problems. I guess the ultimate solution would
be to stop programming.....

 

[Thomas G. Marshall]

I've been wondering if there is a difference in running or building of
jar file between specifying each class in the 'import' statement
versus specifying the package.

My gut instincts tell me that the compiler's have gotten smart enough
(like the C compilers which are extremely sophisticated these days)
that there would only be very minor differences if any between
specifying a class or the whole package.

AFAIK, you are the one specifying what goes into a jar file, no one else,
unless your IDE is trying to be smart and parse the imports for you. If
your IDE isn't trying to slam extra class files in, then it should make no
difference how you import as far as the jar files are concerned.

As an aside, you should really consider a separate import statement for
/each and every/ class file, other than the ones in java.lang.

One of the most important points of import is that it serves as
documentation of the classes in use. It aids the poor slob reading your
code. And it minimizes the chance of tacitly importing two things, and
using the wrong one.

Also, would this make a difference in JBuilder when it generates the
jar file?

Ah....That's what I meant by the IDE, sorry.

 

[Steve W. Jackson]

:I've been wondering if there is a difference in running or building of
:jar file between specifying each class in the 'import' statement
:versus specifying the package.
:
:My gut instincts tell me that the compiler's have gotten smart enough
like the C compilers which are extremely sophisticated these days)
:that there would only be very minor differences if any between
:specifying a class or the whole package.
:
:Also, would this make a difference in JBuilder when it generates the
:jar file?
:
:This is an important question so please be certain of your answer!
:
:Thanks!
:Brett

There is NO actual difference between these two approaches. If you
decide to use an import for each class you reference, you'll have more
lines than if you name an entire package. But these are only used at
compile time to resolve references. If there's any ambiguity in any
class name referenced in your code (that is, it exists in more than one
package named in your import list), the compiler will loudly complain
and force you to resolve it. There are those who maintain that using *
in import statements is unprofessional looking code. I don't agree.
But to each his own.

= Steve =

 

[Jon Skeet]

I've been wondering if there is a difference in running or building of
jar file between specifying each class in the 'import' statement
versus specifying the package.

My gut instincts tell me that the compiler's have gotten smart enough
(like the C compilers which are extremely sophisticated these days)
that there would only be very minor differences if any between
specifying a class or the whole package.

Also, would this make a difference in JBuilder when it generates the
jar file?

This is an important question so please be certain of your answer!

Assuming there are no name clashes, it makes no difference to the
compiled code. However, using import-on-demand (import packagename.*)
could lead to the code not compiling in future, if classes are added to
the packages which lead to name clashes.

When writing imports by hand I used to use import on demand, and I
never saw any problems from doing it. Now, however, I use Eclipse's
"Organise Imports" functionality which means I can have single-class
imports without any extra effort on my part. (I never write any import
statements directly these days. Eclipse even sorts them appropriately
for me.) To me, this is the best of both worlds.

 

[Thomas G. Marshall]

Jon Skeet <[email protected]> horrified us with:

....[thwack!]...

When writing imports by hand I used to use import on demand, and I
never saw any problems from doing it. Now, however, I use Eclipse's
"Organise Imports" functionality which means I can have single-class
imports without any extra effort on my part. (I never write any import
statements directly these days. Eclipse even sorts them appropriately
for me.) To me, this is the best of both worlds.

Jon, do you find eclipse easier to use than IDEA---Have you used the latter?
I'm not thrilled with eclipse.

 

[Jon Skeet]

Thomas G. Marshall

Jon, do you find eclipse easier to use than IDEA---Have you used the latter?
I'm not thrilled with eclipse.

I've tried IDEA a couple of times - I never managed to get past the
irritation stage which almost always accompanies using a new IDE. It
just didn't feel nice to me. I've heard great things about it, but
Eclipse does everything I want it to right now

 

[Neal Gafter]

I've been wondering if there is a difference in running or building of
jar file between specifying each class in the 'import' statement
versus specifying the package.

My gut instincts tell me that the compiler's have gotten smart enough
(like the C compilers which are extremely sophisticated these days)
that there would only be very minor differences if any between
specifying a class or the whole package.

Also, would this make a difference in JBuilder when it generates the
jar file?

This is an important question so please be certain of your answer!

Presuming the line numbers of the code don't change, the resulting class files
will be identical. If they're not, then its a bug. If you're using javac then
it would be my job to fix it. Report your bugs at
<http://java.sun.com/webapps/bugreport/>. If you're using JBuilder, report such
bugs to Borland.

 

[Dale King]

Thomas G. Marshall


I've tried IDEA a couple of times - I never managed to get past the
irritation stage which almost always accompanies using a new IDE. It
just didn't feel nice to me. I've heard great things about it, but
Eclipse does everything I want it to right now

And when you factor in the price tag of IDEA vs. the fact that Eclipse is
free, then Eclipse wins hands down.

Unless IDEA has some sort of neural link with my brain so that I only have
to think of the code without actually typing, I can't see anything to
justify the added cost for me.

 

[Thomas G. Marshall]

And when you factor in the price tag of IDEA vs. the fact that
Eclipse is free, then Eclipse wins hands down.

Unless IDEA has some sort of neural link with my brain so that I only
have to think of the code without actually typing, I can't see
anything to justify the added cost for me.

Given the way my mind often trys to solve n problems at once, such a neural
link might produce some of the most amazing God-awful code in history.
Imagine every fleeting thought written down as a code fragment. As you
thought and rethought, the code would form clearer and clearer, but you
still might end up with a workable bug-free solution that was logically a
mess.