We're updating the issue view to help you get more done. 

AOT compilation can result in spurious ClassCastException during compile

Description

If you try to compile the attached files as follows (assuming they are in "src"):

java -Dclojure.compile.path=out -cp "./clojure-1.8.0.jar:out:src" clojure.lang.Compile implementer protocol consumer

an exception will be thrown:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Exception in thread "main" java.lang.ClassCastException: implementer.Obj cannot be cast to protocol.Dependent, compiling:(consumer.clj:5:1) at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3657) at clojure.lang.Compiler.compile1(Compiler.java:7474) at clojure.lang.Compiler.compile(Compiler.java:7541) at clojure.lang.RT.compile(RT.java:406) at clojure.lang.RT.load(RT.java:451) at clojure.lang.RT.load(RT.java:419) at clojure.core$load$fn__5677.invoke(core.clj:5893) at clojure.core$load.invokeStatic(core.clj:5892) at clojure.core$load.doInvoke(core.clj:5876) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invokeStatic(core.clj:5697) at clojure.core$compile$fn__5682.invoke(core.clj:5903) at clojure.core$compile.invokeStatic(core.clj:5903) at clojure.core$compile.invoke(core.clj:5895) at clojure.lang.Var.invoke(Var.java:379) at clojure.lang.Compile.main(Compile.java:67) Caused by: java.lang.ClassCastException: implementer.Obj cannot be cast to protocol.Dependent at protocol$fn__12$G__8__14.invoke(protocol.clj:3) at protocol$fn__12$G__7__17.invoke(protocol.clj:3) at protocol$expand_deps.invokeStatic(protocol.clj:8) at protocol$expand_deps.invoke(protocol.clj:6) at clojure.lang.AFn.applyToHelper(AFn.java:154) at clojure.lang.AFn.applyTo(AFn.java:144) at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3652) ... 15 more
  • This does not occur with 1.6 or earlier versions

  • This does not occur if you do not try to invoke AOT

  • This may not occur for some orderings of the arguments

This appears to be related to the class being loaded by two different class loaders, and also may result in the namespace being compiled more than once. This issue has popped up for us multiple times in our production build, but it took a while to realize it was a compiler issue and to find a minimal example.

Environment

java version "1.8.0_112"
Java(TM) SE Runtime Environment (build 1.8.0_112-b16)
Java HotSpot(TM) 64-Bit Server VM (build 25.112-b16, mixed mode)

Status

Assignee

Unassigned

Reporter

import

Labels

Approval

Triaged

Patch

None

Affects versions

Release 1.8
Release 1.7

Priority

Major