> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On
> Behalf Of Schewe, Jon (MN65)
> Sent: Monday, October 30, 2000 2:25 PM
> To: [EMAIL PROTECTED]
> Subject: RE: A command to kill extra import statements
>
>
> > Some people confuse what import does with what #include does. With
> > C/C++, #includes actually add code to the source file, and therefore
> > there is more to compile - can be slower if it is a lot of
> code. With
> > Java, import is simply telling the compiler how to resolve
> class short
> > name use to the fully qualified name. (<rant>I dislike the name
> > import; I wish something like "ref" or "refersto" or "link"
> or "uses"
> > or something that clearly states what import does was used
> > instead</rant>).
>
> That's not correct. java compilers compile everything that
> is imported.
> I've run into this problem since I started hacking some code,
> then saved the
> file, it wouldn't compile, then decided that I didn't really
> need it in
> another file, commented out the references, except the
> imports, then tried
> to compile it and got errors from the first file that it
> shouldn't have
> touched.
A Java compiler automatically compiles a referenced class when it finds the
source for the class and the class file is out of date. Out of date means
the .class file does not exist, or is older than the timestamp on the source
file.
> That's not correct. java compilers compile everything that
> is imported.
...only everything in single-type import declarations. Your class file did
not exist and you must have been using single-type import declarations, so
it compiled the imported class even though it only existed in the import
declaration.
In this situation with on-demand imports, only the classes referenced in the
implementation code would be recompiled (if they were out of date).
> Plus global imports make debugging hard because
> it's hard to find
> the correct package for a file if everything is a global
> import.
For manual inspection, C-c C-v C-w, C-c C-v C-y work pretty well!
For debugger work, it finds it for you automatically.
> On the
> projects I work on people are publicly humiliated for using
> global imports,
> it's considered as bad as checking in uncompilable code to
> the repository.
Yes, I as well have flamed others for being lazy on using on-demand imports,
and I do not do that anymore. Unless it is the actual coding standard, it
is not deserved. It is definitely on another level from uncompilable code
checkins. One is a fatal flaw.
> > As a style issue, listing each class is more of a maintenance
> > nightmare than any benefit (class collisions are very rare; import
>
> Rare? Maybe if you only use core java classes, but between
> many 3rd party
> packages this is a definate problem.
>
When a class uses two same-named classes in different packages (the simple
names are the same), at least one of them must be referred to by the fully
qualified class name in the implementation code. Neither single-type nor
on-demand imports solve this issue.
In fact, using only single-type will usually not work. This will not
compile (which surprises me actually):
import pkga.A;
import pkgb.A;
class TestClass
{
pkga.A classA;
}
However, change it to this, and it works:
import pkga.*;
import pkgb.*;
class TestClass
{
pkga.A classA;
}
This one also works, and classA is of type pkgb.A, since it shadows pkga.A:
import pkga.*;
import pkgb.A;
class TestClass
{
A classA;
}
In this situation, I find it clearer to have them all on-demand import
declarations and use fully qualified class names for the conflicts. This is
more consistent with itself, and clearer code.
I look forward to learning more of your experience on this! Thanks for your
reply.
