[izpack-devel] OT: Java Imports in IzPack

[Elmar Grom]

Hi folks,

yes this one of the widely recommended best practice rules, though I have
yet to fathom the advantages. As Klaus mentions, occasionally an ambiguity
arises if two (or more) imported packages contain a class with the same
name. However this is not a problem, just a minor annoyance that is easily
fixed by specific imports. The compiler will never make a pick on its own
(which might be wrong) and thus cause a problem. It will always produce an
error and stop compiling.

Actually the only way to get the wrong class is be USING specific imports
and making a mistake there. But even that is a very remote possibility,
since most likely the API of the two classes will differ enough to cause
problems.

The best benefit that I can see is the fact that you naturally build an
inventory of all the external classes that are used in your code (though I
have yet to make use of this information). This is of course only true it
you are very diligent in also deleting all imports for classes that you have
removed while making changes. Otherwise it only represents a mess.

	Elmar



-----Original Message-----
From: izpack-devel-admin at berlios.de
[mailto:izpack-devel-admin at berlios.de]On Behalf Of Klaus Bartz
Sent: Saturday, March 11, 2006 1:22 AM
To: izpack-devel at berlios.de
Subject: Re: [izpack-devel] OT: Java Imports in IzPack


Hi Hal,
hope no checked in file imports a hole package.
It is one of the "best practice" rules. Sometimes you
will get problems with importing a hole package; if a class
name exist in more than one package.
I (may be the other developer of IzPack also) develop
with eclipse. There it is common to use the proposal from eclipse
for the import statement which will be qualified (until 99 imports
for the same package will be used).
Beginning with this rule it seems stupid, but for me it has these
days a sense. Using unknown a wrong class can be really curious...

Cheers

Klaus

P.S.
For eclipse there is a format description file with
$IzHome/src/eclipse-code-formatter.xml
If you use it, your classes will be have the same outfit as the
common IzPack sources. It's made for old people which are unable
to change formating every source file :-)


Am 11.03.2006, 08:10 Uhr, schrieb Hal Vaughan <hal at thresholddigital.com>:

> This is basically a curiosity thing, but I've noticed that in pretty
> much every class I've looked at in IzPack, the imports are very
> specific, like:
>
> import javax.swing.JButton;
>
> instead of something like:
>
> import javax.swing.*;
>
> which is what I've seen in most examples in tutorials and howto
> articles, including many demos and examples on Sun's own Java sites.
>
> Is there a reason for such specific imports in IzPack?  I ran a few
> tests on a class or two of my own, and there doesn't seem to be any
> difference in class size.  The compile time difference, at least on my
> tests, was within a normal variance, allowing for different test runs
> and different results within each run.
>
> It's not a critical question, but I was just wondering what the
> reasoning was for this or if it's just one coder's habit that has
> caught on.
>
> Hal
> _______________________________________________
> izpack-devel mailing list
> izpack-devel at lists.berlios.de
> http://lists.berlios.de/mailman/listinfo/izpack-devel
>
>
> __________ NOD32 1.1422 (20060301) Information __________
>
> Diese E-Mail wurde vom NOD32 Antivirus System geprüft
> http://www.nod32.com
>
>



--
Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/
_______________________________________________
izpack-devel mailing list
izpack-devel at lists.berlios.de
http://lists.berlios.de/mailman/listinfo/izpack-devel