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
