Compiling a class via `deftype` during AOT compilation gives different results for the different constructors. These hashes should be identical.
This also means that whenever there's a stale AOT compiled deftype class in the classpath, that class will be used rather then the JIT compiled one, breaking repl interaction.
Another demonstration of this classloader issue (from
CLJ-1495) when reloading deftypes (no AOT) :
This bug also affects AOT compilation of multimethods that dispatch on a class, this affected core.match for years see http://dev.clojure.org/jira/browse/MATCH-86, http://dev.clojure.org/jira/browse/MATCH-98. David had to work-around this issue by using a bunch of protocols instead of multimethods.
Cause of the bug: currently clojure uses Class.forName to resolve a class from a class name, which ignores the class cache from DynamicClassLoader thus reloading deftypes or mixing AOT compilation at the repl with deftypes breaks, resolving to the wrong class.
Approach: the current patch (CLJ-979-v7.patch) addresses this issue in multiple ways:
- it makes RT.classForName/classForNameNonLoading look in the class cache before delegating to Class/forName if the current classloader is not a DynamicClassLoader (this incidentally addresses also CLJ-1457)
- it makes clojure use RT.classForName/classForNameNonLoading instead of Class/forName
- it overrides Classloader/loadClass so that it's class cache aware – this method is used by the jvm to load classes
- it changes gen-interface to always emit an in-memory interface along the [optional] in disk interface so that the in-memory class is always updated.