@hiredman: I just reproduced in prod that Var$Unbound issue you reported the other day -- trying to extract a minimum repro example

11:28:38 WARNING: Inst already refers to: #'clojure.core/Inst in namespace: schema.core, being replaced by: #'schema.core/Inst
11:28:41 Exception in thread "main" java.lang.IllegalArgumentException: No implementation of method: :spec of protocol: #'schema.core/Schema found for class: clojure.lang.Var$Unbound, compiling:(social/common/url.cljc:43:1)

weird thing is that it seems to be non deterministic -- one build failed like this, next build built fine

seems to be caused by a stale target/

yep. so the steps to repro are: - AOT compile with alpha4 a project that shadows one of the new c.c vars of alpha5 - bump dependency to alpha5 - try to run project

http://dev.clojure.org/jira/browse/CLJ-1874 will fix this case /cc @alexmiller

I think it's the same issue that was reported in https://groups.google.com/d/msg/clojure/D_s9Drua6D4/9S8CUigXEAAJ

Bleh

Doesn't that affect a whole lot of bytecode?

I can't imagine that's going to fly

yeah, that's 7 extra bytecodes for every def, which is definitely not ideal, but AFAICT is the only way to maintain ABI compatibility when new version of libs add vars that consumers are shadowing

mumble mumble invokedynamic

one of the lesser known things about indy is that it's is an excellent tool to win at the binary compatibility game. you wire up a callsite using an indy instruction, which calls the bootstrap method once. bootstrap method can return different MethodHandles in different versions of clojure -- but the bytecode never changes at the callsite

it's the ultimate in late binding