Completed
Details
Details
Assignee
Unassigned
UnassignedReporter
import
importLabels
Approval
Ok
Patch
Code and Test
Priority
Affects versions
Fix versions
Created May 3, 2012 at 9:01 AM
Updated February 18, 2015 at 10:21 AM
Resolved February 18, 2015 at 10:21 AM
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 with the [optional] on-disk interface so that the in-memory class is always updated.
Patch: CLJ-979-v7.patch
Screened by: Alex Miller