[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.
While class collisions are usually rare, they are often a source of extreme
confusion. Also, from a documentation standpoint when you see a "List" class it
is much easier to resolve this class if the developer used explicit imports
rather than a bunch of .* imports leaving you to search for any matching class
name.
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 ;^)
--
****************************************************
Jim LoVerde, Technical Architect
nVISIA (formerly STR)
http://www.nvisia.com
voice: 312.674.4798 fax: 312.697.3801
mobile: 773.398.9539 pager: [EMAIL PROTECTED]
S/MIME Cryptographic Signature
