I wrote a mini-essay in comments that I need to run into a blog post about how AOT works; https://github.com/griffinbank/rules_clojure/blob/main/java/rules_clojure/ClojureWorker.java

@arohner thanks but in your essay you say this:

// When loading an AOT'd use of a protocol, the
// definition must be AOT'd and on the classpath (because otherwise
// the definition will be loaded from source, and the source and
// consumer protocol definitions will be in separate classloaders, and therefore be not=

how is this not a big problem?

(btw, I'm not interested in whatever workaround you may have come up for this)

Ah sorry, I wasn’t clear. That is a big problem

so this a deal breaker for @borkdude's comment

It is only a problem if you use protocols from non-core libraries, since core is already AOT-ed.

Does CLJS do that?

we use protocols from other dependencies

Ah, interesting. Which one for example?

we would have to audit, but this is simply not interesting at all because who wants to think about this later

Yes. I would say this is a great reason to not AOT at all when publishing a library. However, as a "tool" it is a different use case.

I recently had a related problem. I tried to call a Clojure protocol (as interface) from Java but I couldn't since it was not visible in Java. I ended up rewriting that protocol to a Java interface instead.