commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Gregory <>
Subject RE: import * vs explicit debate
Date Wed, 02 Apr 2003 23:49:35 GMT
Here are my pennies: We uses "explicit" imports as computed by Eclipse's
"Organize Imports" feature. 

Before saving or committing a file, we (usually) all do a
CTRL-SHIT-O/Organize Imports and a CTRL-SHIFT-F/Format. (It would be nice if
this were done automatically when you save a file, someday maybe.) Eclipse
uses "explicit" imports, which I personally like for the following reasons:

(0) It is clearer, no mysteries.

(1) You can see how "involved" or coupled a type is in other packages'

(2) You can see at a glance if a type is using something it should not. For
example, importing some "old" internal Base64 class instead of the
"standard" Base64 class.


"Import statements must be fully qualified for clarity." from

"All import statements should containing the full class name of classes to
import and should not use the "*" notation" from


-----Original Message-----
From: Alex Chaffee / Purple Technology [] 
Sent: Wednesday, April 02, 2003 1:33 PM
To: Jakarta Commons Developers List
Subject: import * vs explicit debate

OK, fine, it looks like the debate is raging already, so I'll chime in:

On Wed, Apr 02, 2003 at 03:19:45PM -0500, Henri Yandell wrote:
> Biggest pain for me was discovering a large codebase with a lot of
> unfamiliar package names that were all .* imported. Made it quite hard to
> have a clue what things were.

So it's an educational thing?

If unfamiliar source code uses a class Foo, then you must (a) discover
what package Foo is in, and (b) read the docs for it.  You're saying
that explicit imports help with (a), but they can't help with (b),

Modern IDEs, help browsers, and the JavaDoc all-classes index all
allow you to accomplish (a) very easily. For instance, auto-complete
or tag-aware IDEs (including Emacs) let you click or keystroke on a
symbol and jump right to the definition for it.  

But the main counter-argument is, this is only useful in the very
beginning of your use of an unfamiliar source file -- or rather, of a
source file that uses an unfamiliar package.  As soon as you have a
basic comprehension of the package, the disadvantages of having a huge
list of explicit imports outweigh that one advantage.  

I'd rather optimize for the 95% case than the (admittedly occasionally
confusing) 5% case.

> There is the clash example as well of course. java.util.Data/java.sql.Date
> and others.

That's a problem that's been solved since Java 1.0.  

import java.util.*;
import java.sql.*;
import java.util.Date;

It's actually clearer this way, since the final line is explicitly
saying "Date is a clash -- watch out" rather than burying the
potential clash in a big-ass list.

> The usual argument against being anti .* is that IDE's can be used to
> figure out where a package lies, 

"against being anti?"  :-)

My two favorite IDEs, IDEA and Eclipse, have both Optimize Imports and
Auto-Complete.  With * imports, that means that once I use one class
in a package, I get auto-complete for all classes in that package.
This makes my development much smoother.  

I get to type

	Map map

then IDEA's lightbulb asks me if I want to import, so Alt-Enter-Enter
adds import java.util.* up at the top of the file, then I type

	 = new Ha

then Ctl-space autocompletes "shMap" since it's already imported an
in the symbol table.  But with explicit imports, I couldn't get that
auto-complete -- I'd have to type out "HashMap" and then
Alt-Enter-Enter import it too.  

Even more compelling is using auto-complete as a package documentation
browser.  If I don't remember the full name of a class, I can type
what I think the first few letters are, and I see all names that match
in all imported packages.  Again, with explicit imports, I don't have
that information.

> but that argument is quite poor as the
> IDE can also be creating nice import statements.

And which set of import statements is more "nice" --

import java.util.Map;
import java.util.HashMap;
import java.util.TreeMap;
import java.util.ArrayList;
import java.util.List;
import java.util.ArrayList;
import java.blah.Blah;
import ad.Nauseam;


import java.util.*;
import java.blah.*;
import ad.*;

To my eye, the latter is more nice.

> The other argument is that the imports use up lots of space. IDEs can wrap
> up the imports into one line. More of a pain for text-editor users.

But whether they're collapsable or not, when expanded, the big lists
are much harder to grok.  Essentially they serve as targets for a find
command -- and I prefer an explicit "find symbol by name" function
which is more reliable anyway.

> > - Inability to tell specific dependencies just by glancing at the source
> > code

And this is important why?  And how often is it useful?

> > - Increased difficulty when refactoring, either manually (with grep /
> > perl) or by IDEs that support refactoring and nearly always require
> > import cleanup as a preliminary step.

Huh?  I've been refactoring, manually and with tools, for a couple
years and I find it *easier* to do with .* imports.  

Using manual imports, it means that if I move a method that uses class
C from class A to class B, there's a good chance that C is already
imported (via *) inside B, so I don't have to change the imports at
all.  And once I do add C's package to the imports list, the next
refactorings have it available.

Automated tools, as you mention, do the right thing no matter what.

I use Optimize Imports primarily to remove unused packages from the
import list.

> > >>Import .* is annoying 

I disagree :-)

> > > and all the jakarta projects should have import
> > >>cleanups as part of their build.xml IMHO.

I agree -- but with them cleaned to all use *.

Alex Chaffee                     
Purple Technology - Code and Consulting
jGuru - Java News and FAQs       
Gamelan - the Original Java site 
Stinky - Art and Angst           

To unsubscribe, e-mail:
For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message