----- Original Message -----
From: "Jim LoVerde" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, October 30, 2000 8:25 PM
Subject: Re: A command to kill extra import statements
> [EMAIL PROTECTED] wrote:
>
> > This type of statement: > Global imports really can cause problems and
> > definatly slow down compiles. is a strong statement and I have yet to
> > see it justified with Java and find it misleading. This is a first I
> > have heard that it is slower. Do you have actual test results that
> > Java compiles slower with type-import-on-demand? I will have to try
> > an experiment some time.
>
> This did pose some performance problems with earlier compilers, however
most
> modern compilers suffer little if any impact (and these days you might
even argue
> that the extra parsing of explicit imports is a larger impact). In the
end, I am
> pretty sure that this comes out as a wash today (haven't run any recent
tests but
> somewhere around JDK 1.1.6 any compilation impact seemed to have
disappeared).
>
> > As a style issue, listing each class is more of a maintenance
> > nightmare than any benefit (class collisions are very rare; import
> > statements are not a reliable source of class dependencies). The new
> > JDE features to clean up the import list goes a long way to help this,
> > though. Thanks for creating it!
>
> Regarding style and maintenance, I vehemently disagree for this reason:
> maintenance is defined as changing code, correct? Well consider this
scenario:
>
> 1. You write a class called FooWidget that imports java.awt.*
> 2. You complete your testing of this class and it is good.
> 3. A new JDK comes out with a java.awt.FooWidget class.
>
> So without changing a single line of your code, you will discover that
when
> trying to compile with the new JDK your class has been broken. Had you
used
> explicit imports this would not have happened.
This is probably off topic, but might just squeeze in if it affects how JDE
is written in the future. I have to agree with Jim here, but for a slightly
different reason. Suppose that you are working on a large project, and are
reading the source code. You come across code like "Connection connection =
new Connection():" There might be half a dozen packages in which a class
called Connection might live. If all imports are explicitly at the top you
can do a control-s and have your answer instantly. With package imports it
can be slow to find, and thus increases maintenance time.
> But alas, this is yet another religious issue that seems to create almost
as much
> furor among developers as the simple rule that you should never use tabs
in your
> source code ;^)
I agree. Which probably means any commands doing stuff with imports should
support both methods of working. Even if one is wrong :-)
Nick
