commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject Re: import * vs explicit debate
Date Mon, 07 Apr 2003 21:38:41 GMT
My 2c: 

- if you use an editor that supports explicit imports - it doesn't matter 
if it's one way or the other.
- if you use an editor that supports simple navigation ( click some keys
and you go to the class definition ) - again it doesn't matter.

- if you use vi/emacs or another fast editor ( which doesn't support 
explicit imports ) - implicit imports is a _huge_ pain, and very little
could justify it. Even if you take the pain, it's very likely you'll
soon end with many unused imports ( and more pain if you want to clean them
). Pain is not good, it kills the fun of programming. 

So my opinion is that everyone should write in whatever style he is
comfortable with. If you happen to use an editor that can reorganize
the imports and you edit a file that has * imports ( or has unused imports
)- then it is a good idea to hit the magic keystroke and convert.

It would be a bad idea IMO to require people using vi/emacs/etc to manually
do what can be easily automated. 

( after using xdoclet for a while - you'll get the same feeling about
writing standard mbeans, EJB or taglibs ).


>> 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),
>> right?
>> 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;
>> or
>> 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:

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

View raw message