Fork me on GitHub

A dep that includes log4j in its jar


many libs misbehave by bundling deps


(usually this only gets noticed when you realize you are using the wrong version of some lib...)


A nightmare in this scenario


also log4j is a likely candidate for that kind of bundling, because the lib authors want to bake in logging features...


Hard to get rid of with out getting rid of the dep, annoying to track down which dep is behaving badly


Basically you have to look at all the jars of your deps and see if they contain log4j classes


this does seem like something a plugin could do, logging out class files in deps / searching for classes matching some pattern and reporting their provenance


Some way to bind class file name prefixes to maven coords

Alex Miller (Clojure team)00:12:49

There are some that do this, although I don't recall the names

Alex Miller (Clojure team)00:12:32

Probably findable here via search, they've been discussed

Adam Kalisz01:12:58

tools.logging is a dependency of e.g. Aleph or it seems.

Alex Miller (Clojure team)01:12:00

tools.logging does not depend on log4j

Alex Miller (Clojure team)01:12:01

tools.logging can use log4j as an underlying framework, if you also provide log4j as a dependency and its either explicitly configured or automatically found via the load order at

👍 2
Ben Sless06:12:04

Anyone here ever played with ferns and frons?

🌿 1
respatialized15:12:15 I watched this talk not too long ago and it seems like there may be some overlap (the static/dynamic gap notwithstanding) between these ideas - namely, that of decoupling sequential processing from the "array" representation: > The main message of this talk is that "array algorithms" are often not naturally array algorithms at all, but rather an error-prone, composition-resistant enmeshing of a safe, simple, and illuminating algorithm on a natural (non-array) data type, together with details of decoding from and encoding to arrays.

👀 1

Conal Elliot uses the ideas in that talk to make the Fast Fourier Transform "portable" across different data structures in a provably correct way, comparing its performance on a tree to its performance on a;gbpv=1&amp;dq=bush+data+structure&amp;pg=PA158&amp;printsec=frontcover.