what java version are you using? (not sure if it's relevant..)

perhaps one of your dependencies downgrades ASM

it seems we have a conflict on ASM

❯ clj -Sdeps '{:deps {clj-kondo/clj-kondo {:mvn/version "2023.09.07"}}}'
Clojure 1.11.1
user=> (require '[clj-kondo.hooks-api :as hooks])
nil
user=>

sorry for the noise 🙂

if anyone else finds this, it was eastwood on the classpath

jonase/eastwood 1.4.0
  . org.clojars.brenton/google-diff-match-patch 0.1
  . org.ow2.asm/asm-all 5.2

user=> (io/resource "org/objectweb/asm/Opcodes.class")
#object[java.net.URL
        "0x37e9d2e2"
        "jar:file:/Users/dan/.m2/repository/org/ow2/asm/asm-all/5.2/asm-all-5.2.jar!/org/objectweb/asm/Opcodes.class"]

when using tools, it's usually best to separate their classpaths. deps.edn got this right with -T(ools) usage

unless you want to invoke them all from the same JVM of course

agree. we have a dev alias which has some stuff that we’ve been pretty casual about. i guess the classpath finally shifted around and now it’s finding those bundled 5.2 versions instead of a 9.4 version

i think eastwood needs to live on your regular classpath because it runs your tests and requires all of your code. but your point is still valid

good point about eastwood

I run Eastwood as a standalone process via build.clj in HoneySQL https://github.com/seancorfield/honeysql/blob/develop/build.clj -- why do you have it on the dev classpath @U11BV7MTK?

that’s a great question. i think because dev became a grab bag of “handy” stuff. Although I’m not sure if there’s a dev related workflow for eastwood. we even have an alias for it for CI. I suspect it was considered “dev” tooling and perhaps someone might want it

i need to build a tool to identify all classes on the classpath that are duplicated. because it’s wild that we have asm-all and asm with such different versions. and so the version of that class you get is completely undefined. i guess bumping some versions shifted which came first on the classpath

This is why I don't even really like nREPL/CIDER on my dev classpath 😉

hasn’t been on mine for years now

i thought you were exclusively nrepl these days

Yeah. Calva needs it. And CIDER for all things to work.

With remote processes, I only have nREPL, no CIDER, and only in a couple of internal-facing apps (they have "everything" so I don't need to connect to any other processes).

cider-nrepl shades everything so it shouldn’t be an offender for that reason

cider/cider-nrepl 0.37.0
  . nrepl/nrepl 1.0.0
  . mx.cider/logjam 0.1.1

oh yeah. a decent chunk of code. but the classes will be renamed. i’m not familiar with logjam. i haven’t followed development too much recently

I don't follow nREPL/CIDER dev at all -- I mostly just pretend it doesn't exist and let Calva add the dependencies at jack-in or pull a "RELEASE" version from an alias 🙂

I hit this issue, but for another reason: mranderson was part of the Lein :plugins. > when using tools, it's usually best to separate their classpaths. deps.edn got this right with -T(ools) usage This. Normally I try for every tool to go under a separate Lein profile e.g.:

:clj-kondo {:plugins [[com.github.clj-kondo/lein-clj-kondo "2023.09.07"]]}