what are "import" statements exactly ?

[Guest]

I am a scientist who occasionally programs also in java (self-learning
on the Sun tutorials), and I'd like to know one thing about the "import"
statement which I haven't found clearly explained around.

Are import statements resolved at compile time (like C #include
directives or Fortran INCLUDE statements) ?

Or are they resolved at run time (like a reference to a library
subroutine, with CLASSPATH doing similarly to LD_LIBRARY_PATH for shared
libraries) ?

I find slightly painful to have to insert "the right list" of import
statements. Sometimes with wildcards (import javax.swing.*) and
sometimes explicitly (import javax.swing.table.AbstractTableModel), with
wildcards sort of not finding a subcomponent.

Will a class file compiled with lots of wildcard import be bigger or
less efficient than one with a few specific import ?

 

[Andreas Leitgeb]

I'd like to know one thing about the "import"
statement which I haven't found clearly explained around.

You can think of "import", like setting the PATH at the
beginning of a script:
If inside the script you'd call all commands with
absolute paths, like /usr/bin/awk, then you don't
really need the PATH, but if you call just "awk",
then the PATH will be searched for directories
that contain an executable named "awk".
This comparision is very shallow, so don't try to
stretch it further than that.

Back to Java: with "import" you tell the compiler where
to search for classes that are named in the java-source
without a full path. The compiler then uses this information
and the resulting .class file only contains the resolved paths
to each class. There is no such lookup for classes at runtime!

 

[Jeff Higgins]

I am a scientist who occasionally programs also in java (self-learning on
the Sun tutorials), and I'd like to know one thing about the "import"
statement which I haven't found clearly explained around.

Are import statements resolved at compile time (like C #include directives
or Fortran INCLUDE statements) ?

Or are they resolved at run time (like a reference to a library
subroutine, with CLASSPATH doing similarly to LD_LIBRARY_PATH for shared
libraries) ?
http://java.sun.com/docs/books/jls/third_edition/html/names.html

I find slightly painful to have to insert "the right list" of import
statements. Sometimes with wildcards (import javax.swing.*) and sometimes
explicitly (import javax.swing.table.AbstractTableModel), with wildcards
sort of not finding a subcomponent.

import java.awt.*
import java.util.*

List myList;

Will a class file compiled with lots of wildcard import be bigger or less
efficient than one with a few specific import ?

No.

 

[Hendrik Maryns]

LC's No-Spam Newsreading account schreef:

I am a scientist who occasionally programs also in java (self-learning
on the Sun tutorials), and I'd like to know one thing about the "import"
statement which I haven't found clearly explained around.

Are import statements resolved at compile time (like C #include
directives or Fortran INCLUDE statements) ?

Or are they resolved at run time (like a reference to a library
subroutine, with CLASSPATH doing similarly to LD_LIBRARY_PATH for shared
libraries) ?

I find slightly painful to have to insert "the right list" of import
statements. Sometimes with wildcards (import javax.swing.*) and
sometimes explicitly (import javax.swing.table.AbstractTableModel), with
wildcards sort of not finding a subcomponent.

Will a class file compiled with lots of wildcard import be bigger or
less efficient than one with a few specific import ?

Nope. ‘import’ is purely something from the compiler. The statements
are used to figure out what you intend when you write ‘Date’, is it
java.util.Date or java.sql.Date. Nothing is left from it in the
compiled class file.

You do use a proper IDE, do you? Eclipse takes care of all imports
quasi-automatically, and it can do ‘Organize imports’ each time you save.

H.
--
Hendrik Maryns
http://tcl.sfs.uni-tuebingen.de/~hendrik/
==================
http://aouw.org
Ask smart questions, get good answers:
http://www.catb.org/~esr/faqs/smart-questions.html

 

[Jeff Higgins]

Jeff Higgins wrote:>

http://java.sun.com/docs/books/jls/third_edition/html/names.html

Also see 12 Execution:
<http://java.sun.com/docs/books/jls/third_edition/html/execution.html>

 

[Andreas Leitgeb]

No.

Really: "No, but ..."

.... with a really large list of import-statements, compile-time will
increase, and what's worse: the general likeliness of the compiler
picking a "wrong" class will be higher. Equal class-names can occur
in different packages. If two packages with some common class-names
are imported, then the compiler picks one, and that isn't necessarily
the one *you* had in mind. This problem can even occur when a
certain java-source has no "import"-statement at all, but in the same
package there are other classes with names like classes from java.lang
since both that and the current package are implicitly imported.

PS: Of course, "unexpectedness" often depends on the one not expecting

 

[Jeff Higgins]

Really: "No, but ..."

... with a really large list of import-statements, compile-time will
increase, and what's worse: the general likeliness of the compiler
picking a "wrong" class will be higher. Equal class-names can occur
in different packages. If two packages with some common class-names
are imported, then the compiler picks one, and that isn't necessarily
the one *you* had in mind. This problem can even occur when a
certain java-source has no "import"-statement at all, but in the same
package there are other classes with names like classes from java.lang
since both that and the current package are implicitly imported.

PS: Of course, "unexpectedness" often depends on the one not expecting

Maybe we can learn two things from this.

Don't import names we don't use.
Don't reuse common names.

I'm not sure how your 'Really: "No, but ..." ...' effects

Will a *class file* [my emphasis] compiled with lots of wildcard import
be bigger or less
efficient than one with a few specific import ?

 

[Chase Preuninger]

In java byte code you must always fully qualified the class name so
therefore it is probably converted at compile time.

 

[David Segall]

I find slightly painful to have to insert "the right list" of import
statements. Sometimes with wildcards (import javax.swing.*) and
sometimes explicitly (import javax.swing.table.AbstractTableModel), with
wildcards sort of not finding a subcomponent.

Remove the pain by using NetBeans. Right click on your source file and
choose "Fix Imports". It will remove any imports you no longer need
and will add the new imports you do need in alphabetic order. If there
are possible ambiguities it will list them for you to choose.

 

[Andreas Leitgeb]

Which was a (100% agreeing to Jeff) "No", as well, plus some extra caveat,
which I think was useful to know as well. The just plain "No" could have
been taken as a hint, that there was no reason to ever trim the import list.

PS:
Thanks for correcting my error about compiler's behaviour in
certain ambiguous cases. It errors, rather than picking one.

 

[Andreas Leitgeb]

I'm not sure how your 'Really: "No, but ..." ...' effects

Will a *class file* [my emphasis] compiled with lots of
wildcard import be bigger or less efficient than one
with a few specific import ?

Only to the degree, that in (relatively lucky) cases of
superfluous import'ing the class-file might not even be
generated (since the compiler detects import-ambiguity).
In other cases of non-recommended import-usage, the
programmer may wrongly believe a different class to
be used than the compiler actually uses. The likeliness
of such an goof happening is higher with an excessively
long import-list.

If through such an error a class with a longer path is
chosen, then aside from being wrong, the class-file is
also bigger, since it contains the longer path to that
one class

PS: I hope I've not goofed this time.

 

[Jeff Higgins]

PS: I hope I've not goofed this time.

Well, in light of the other responses
I'm see that I goofed my first response.

Patricia Shanahan
Most succinct, correct, and complete.

Hendrik Maryns, David Segall, perhaps others?
Advantages of an IDE.

 

[Roedy Green]

I am a scientist who occasionally programs also in java (self-learning
on the Sun tutorials), and I'd like to know one thing about the "import"
statement which I haven't found clearly explained around.

see http://mindprod.com/jgloss/import.html
http://mindprod.com/jgloss/package.html

They are unlike the importing facilities of other languages. Assuming
they are the same is the biggest hurdle.

 

[Mark Space]

Remove the pain by using NetBeans. Right click on your source file and
choose "Fix Imports". It will remove any imports you no longer need
and will add the new imports you do need in alphabetic order. If there
are possible ambiguities it will list them for you to choose.

Ditto and David beat me to it.

Get NetBeans. Use it.

Other IDEs probably work the same but I have no experience with others
right now.