I couldn't agree more with Craig. I have come across the exact
situation he describes, where there exists classes:
com.foo.a.ClassA
com.foo.a.Utils
org.bar.ClassB
and you have code:
// MyClass.java
package com.acme.c;
import com.foo.a.*;
import org.bar.b.*;
[...]
public void myMethod()
{
Utils = new Utils();
// etc.
}
If a class org.bar.b.Utils is added to a latter release of org.bar's
library, there is now an ambiguous reference to Utils. It appears that
most of the other arguments for or against explicit importing are
style- or ease-of-use related. That being the situation, the case
illustrated above should clinch the argument. import *; can result in
code that won't compile.
- Neil
--- "Craig R. McClanahan" <craigmcc@apache.org> wrote:
>
>
> On Wed, 2 Apr 2003, David Graham wrote:
>
> > Date: Wed, 02 Apr 2003 13:15:03 -0700
> > From: David Graham <dgraham1980@hotmail.com>
> > Reply-To: Jakarta Commons Developers List
> <commons-dev@jakarta.apache.org>
> > To: commons-dev@jakarta.apache.org
> > Subject: RE: [collections] XxxUtils inner classes
> >
> > >Import .* is annoying and all the jakarta projects should have
> import
> > >cleanups as part of their build.xml IMHO.
> >
> > Out of curiosity, why is importing .* annoying?
> >
>
> I think it's "dangerous" and "fragile" more than "annoying". It's
> possible that a new class will get added to your package, or the one
> you
> are importing, which will result in broken compiles of previously
> working
> code. It also obfuscates where classes you use are actually defined,
> which makes reading code harder than it should be.
>
> > David
>
> Cra
> > >
> >
> >
> > _________________________________________________________________
> > The new MSN 8: smart spam protection and 2 months