Jigsaw prototype, take 2

Tim Boudreau niftiness at gmail.com
Fri Sep 6 20:22:27 PDT 2013


Gregg,

We've worked together and I respect your judgement.  That said, I have to
disagree pretty strongly with the idea of *not* enforcing that dependencies
be a directed acyclic graph as the default.

Fundamentally, if you are developing two things, and there is a circular
dependency between them, you do not have *two* things - you have one thing
which you enjoy pretending is two.  If neither can exist without the other,
their independence is in illusion.

I agree that sometimes you need that sort of thing, dealing with legacy
software and so forth.  Not too long ago, I did some detangling of a
project for a company that could only compile their software if they
compiled against (and shipped) two historical versions of their own
product, and not a soul there actually knew what got loaded and linked at
runtime.  Terrifying but true.

But that being the default is the source of a *lot* of problems.  And
having to understand dependencies teaches understanding of dependencies,
which affects how developers think about designing software.

And explicit, non-cyclical dependencies make possible - trivial, even -
very useful sorts of static analysis.

I've developed a similar attitude toward Maven.  Flexibility can be
harmful, especially when there's no obvious right way to do things - it
gives you enough rope to hang yourself.  I've seen so many Make and Ant
based projects where there was only one person in the organization who
understood how their build system worked.  Maven is inflexible in the
extreme - there's a lot I really dislike about it.  But it is utterly
unambiguous.

Managed dependencies are like that.  You *want* inflexibility as a default.
 Sure, you also want the ability to write your own classloader (IMO,
bytecode-over-the-wire is still one of the actually interesting things
about Java) and do what you want - the occasions are rare, but when you
need it, you need it.  But even when you *do* need it, what are you loading
those classes *from*?  If it's non-trivial and you want it to work, you
need...its dependencies!  So I suspect even when you're doing wild-west
classloading, there are still benefits to having this stuff be explicit and
unambiguous.

I understand that for a lot of people, this JSR is about making the JDK
leaner and meaner.  But I think there are opportunities here to do things
that dramatically reduce the maintenance cost of new software written in
Java, and it would be a pity not to seize the opportunity to kill two birds
with one stone.

-Tim


More information about the jigsaw-dev mailing list