RE: [jgrapht-developers] Jalopy update

[Barak N. <ba...@3p...>]

> One of the things we lost in moving JGraphT to JDK 1.5 was the ability
> to use the old open-source version of Jalopy.  To keep things simple, =
I
> have purchased a copy of the commercial one and will run it myself.  =
So,
> you don't need to worry about running Jalopy before checkin; I'll get
> around to modified files sooner or later (at least before each =
release).

Btw, I think there is a cool feature of Jalopy that allows running it on =
the
server-side as a pre-checkin script.  If applicable, it could be useful =
--
that is, transparently format the code whenever a developer checks in.=20

> I just checked in a reformat of the entire codebase.  As part of this, =
I
> changed the settings to match my style preferences in order to make my
> maintenance job easier.  Probably the most controversial change is to
> collapse imports (e.g. import java.io.*) instead of expanding them.
> These days IDE's all make it easy to see where a class is coming from
> wherever it is used, so I don't think maintaining the class-level
> clutter at the top of the file has any benefit.

I still think the explicit list of import is preferable.  To be
argumentative, modern IDE's do indeed show where the class is coming =
from,
but they also do clever folding :)... One can automatically unclutter =
the
import list by letting the IDE fold it (I think it's even the default in
Eclipse)... =20

But now seriously; I have a better reason. =20
Import such as java.util.* "contaminates" the namespace with unrelated
classes that might cause name collision.  To demonstrate how this
contamination can cause problems, let's suppose that Sun adds a
java.util.UndirectedGraph interface in jdk 1.6, and let's also suppose, =
that
JGraphT, for good reasons, does not immediately upgrade to 1.6 (we know =
it
took a while to update to 1.5).=20

Now, we, in JGraphT, program against 1.5 so everything compiles =
cheerfully,
passes the unit tests, and we're happy and proud.  An enthusiastic =
developer
who has already rushed to use 1.6 downloads JGraphT, attempts to compile =
it
and... starts swearing...  The import section of, say, =
AbstractBaseGraph,
contains:

  import java.util.*;
  import org._3pq.jgrapht.*;

which leads to a name collision -- the code doesn't compile. =20

If a name collision with Sun sounds imaginary, a collision with JGraph
wouldn't be that hard to imagine.  Anyway, the use of wildcards for =
imports
(regular or static) can cause problems that happen only in the "field" =
and
can easily escape detection and correction in the "lab".  After =
painfully
experiencing such problems, one is compelled to decide to never again =
use
wildcards for imports, static or otherwise.  And if the clutter could be
easily handled by the IDE, the decision comes with no sacrifice...

Would you reconsider?

Barak=20