[CLJ-979] map->R returns different class when invoked from AOT ccode Created: 03/May/12 Updated: 13/May/12
|Affects Version/s:||Release 1.3, Release 1.4|
Mac OS X 10.5, lein 1.7 and lein 2.0
(defrecord Dontwork [a])
(= (type (Dontwork. nil))
Will return true if the namespace is not AOT compiled and false if it is.
I have created a small example project with AOT and non-AOT namespaces to demonstrate
|Comment by Scott Lowe [ 12/May/12 9:05 PM ]|
I can't reproduce this under Clojure 1.3 or 1.4, and Leiningen 1.7.1 on either Java 1.7.0-jdk7u4-b21 OpenJDK 64-Bit or Java 1.6.0_31 Java HotSpot 64-Bit. OS is Mac OS X 10.7.
Edmund, how are you running this AOT code? I wrapped your code in a main function and built an uberjar from it.
|Comment by Edmund Jackson [ 13/May/12 2:20 AM ]|
I have two use cases
2. My original use case, which I've minimised here, is an AOT ns, producing a genclass that is called instantiated from other Java (no main). This produces the same error. I will produce an example of this and post it too.
|Comment by Edmund Jackson [ 13/May/12 4:23 AM ]|
Here is an example of it failing in the interop case: https://github.com/ejackson/aotquestion2
git clone firstname.lastname@example.org:ejackson/aotquestion2.git
and it dies with this:
Exception in thread "main" java.lang.ClassCastException: cljside.core.Dontwork cannot be cast to cljside.core.Dontwork
The error message is really confusing (to me, anyway), but I think its the same root problem as for the REPL case.
What do you see when you run the above ?
|Comment by Scott Lowe [ 13/May/12 8:41 AM ]|
Ah, yes, looks like my initial attempt to reproduce was too simplistic. I used your second git repo, and can now confirm that it's failing for me with the same error.
|Comment by Scott Lowe [ 13/May/12 10:35 PM ]|
I looked into this a little further and the AOT generated code looks correct, in the sense that both code paths appear to be returning the same type.
However, I wonder if this is really a ClassLoader issue, whereby two definitions of the same class are being loaded at different times, because that would cause the x.y.Class cannot be cast to x.y.Class exception that we're seeing here.