I couldn't agree more.

It really boils down to the simple fact that class loading in the JVM - for 
the standard classloaders - is well-defined.

If a build tool is not able to reflect this, it is an unreliable build 
tool. It doesn't matter if anyone thinks CLASSPATH order shouldn't matter 
from a philosophical point of view. (And inconveniencing deps.edn users to 
go tell the authors of dependencies to "fix their resources" is not a 
realistic approach)

Providing dependencies in an unsorted map like deps.edn is doing now is 
inherently unstable. 
That doesn't necessarily make deps.edn unusable, but - as others have 
pointed out - a source of surprising errors.
Until an order is defined that survives changing OS/JVMs, I will advise 
anyone to not use deps.edn.

Furthermore, all build tools - with the exception of Bazel and derivates - 
do rely on transitive dependency resolution and thus also are inherently 
But either through established practices or defined standards: they offer a 
way to define an order should conflicts arise.
(Take a look at https://issues.apache.org/jira/browse/MNG-1412 again for a 
longer discussion).

At the very least: The location of your own classpath entries must be 
well-defined. They are by default first on regular CLASSPATH.
I wasn't following the latest development on this, but I would assume that 
is a reasonable demand and has been fixed in newer tools.deps versions?


On Sunday, September 13, 2020 at 8:37:31 AM UTC-7 Matching Socks wrote:

> Too fragile.  This reminds me of the notion of "situated programming", 
> featured in the talk by Rich Hickey:  you and your programs operate in the 
> middle of a bizarre and changing situation.  For Clojure, the Java 
> ecosystem is part of that situation.  Even if some jars do not overlap 
> today, you will be forced to take a minor update someday that introduces a 
> clash.  Or perhaps (quite likely) jars do overlap today, but you will take 
> a minor update someday that causes the classpath to emerge from the 
> hash-map differently and your program won't work anymore.  The insight of 
> the theory of "situated programs" is, not to hit a cliff when a perfectly 
> legal quirk arises in the situation.

You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your 
first post.
To unsubscribe from this group, send email to
For more options, visit this group at
You received this message because you are subscribed to the Google Groups 
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to clojure+unsubscr...@googlegroups.com.
To view this discussion on the web visit 

Reply via email to