commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: import * vs explicit debate
Date Thu, 03 Apr 2003 20:09:52 GMT

On Thu, 3 Apr 2003, Alex Chaffee / Purple Technology wrote:

> Date: Thu, 3 Apr 2003 09:49:26 -0800
> From: Alex Chaffee / Purple Technology <>
> Reply-To: Jakarta Commons Developers List <>,
> To: Jakarta Commons Developers List <>
> Cc:
> Subject: Re: import * vs explicit debate
> Craig -
> I'm not trying to be argumentative here, but I'd like to understand
> your position (and clarify mine).
> The situation I was describing was as follows:
> Project A uses Library X.jar (v1.0).  Alphonse is a developer on
> Project A.
> Xavier is a developer on Project X.  He updates Project X and
> publishes a new version of Library X.jar (v1.1).
> Alphonse imports the new version of X.jar into Project A.
> Now, I think we'd agree that Alphonse should do a full build of
> Project A before he checks in the new version of X.jar, right?

Absolutely.  Promises of binary-level backwards compatibility are very
hard to achieve, because they can be broken by changes in the inheritance
hierarchy of a class in A (say, you factor an implemented interface into
two different ones), even though the set of public methods visible to
users has not changed.

> That's the stage I was talking about.  Since Alphonse had to
> explicitly import the new version of X.jar, he has a pretty good idea
> that any compile errors that say "ambiguous class involving
> org.X.SomeClass" are due to interface changes introduced in the X.jar
> he just imported.

Yes, he will understand this error message, but why should he have to?  If
Alphonse always used explicit imports, this kind of error message would
never show up at all, and his build would have never been broken.

> Your argment seems to be that Xavier should not be responsible for
> recompiling and fixing Project A (and all other clients of Library X).
> I totally agree with you there.

I was actually arguing that Xavier should not need to go ask Alphonse for
permission to add a new class to X -- which is what I thought you were
suggesting.  If I misread your train of thought on this, I'm sorry.

> But the Maven/Gump procedure is messing with that scenario a bit.  Are
> you saying that it promotes *automatic* updates of all clients when a
> library is updated?  In that world, Alphonse does not exist; he is
> replaced by a script (or just an automatic Ant-based web download).

Nearly all of the Maven project files I have seen ask for specific
versions of their dependencies.  You can override this locally if you want
to say "no matter what the project file says, *I* want to use this
particular version of a dependent JAR"), but I would bet most people don't
actually do it.

If Alphonse is using Maven, he'd simply update the version number for
Project X in the project descriptor file, and rerun the build.  You might
indeed get "ambiguous class" warnings, but why should you have to?
Dealing with them is a waste of time when they could have been avoided in
the first place.

> This scenario is a little troubling, since it introduces the
> possibility of semantic changes as well as syntactic ones.

Dealing with "ambiguous class" error messages is simply annoying.  Dealing
with semantic changes where Alphonse introduces a new class in A that
happens to shadow a class of the same name in X, and happens to have
public methods with compatible signatures, is dangerous -- Alphonse has
now got a totally mysterious semantic change in A, without any compiler
errors to warn him about it.

>  This
> transcends the import issue.  If this is so, is there a rationale for
> it somewhere I can read up on?

A rationale for what?  If it's for explicitly defining dependencies in a
Maven project file, the whole point is to automate the entire build
process.  For an example of how painful it can be without this, go grab
the source code for Tomcat 4.0, and assemble the right versions of the 25
or so external dependencies manually :-).

> Note that I actually think this procedure is great, and can accelerate
> development, as long as everyone involved understands the risks.

If "this procedure" means use "*" imports, I disallow it on my for-pay
projects where I have architectural responsibilities, for the reasons
outlined above.  For my Apache work, you'll never see a wild card import
in any of the code I write, because it's much easier to avoid ambiguous
classes in the first place than to deal with them later.  And for the
projects where the other committers listen to me (Struts, the commons
packages that I'm directly working on), you'll see consistent use of
explicit imports as well.

I'm pretty good at creating bugs all by myself -- it just makes sense to
avoid practices that are likely to create more of them simply by an
unfortunate choice of a new class name :-).

> Cheers -
>  - A


> > > No; it's a reason for doing a full clean build and unit test run
> > > before checking in any changes.
> > >
> >
> > That only works for code in your own packages -- not in packages you
> > depend on from other people (especially those that you use binaries for,
> > as things like Maven encourage you to do even if the underlying package is
> > open source).
> >
> > > This way whoever added org.apache.Thing, or updated the library that
> > > added it, is responsible for not breaking everyone else's build.
> > >
> >
> > In other words, I (as the author of one or more commons components) is
> > supposed to ask ***every*** user of that component "will adding a new
> > class Foo in my package cause your build to break?"  Yah, right.
> >
> > It's not my problem.  It's the problem of the person who used "*" imports.
> >
> > Craig
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail:
> > For additional commands, e-mail:
> >
> --
> 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