Yeah I tried this with RoboVM, but there are so many classes that needed to be stubbed that it turned into an endless rabbit hole, so I gave up. It may be a good solution for those who just have one or two problematic classes, though.
On Thursday, December 26, 2013 8:37:44 PM UTC-5, Colin Fleming wrote: > > In case anyone is interested in a workaround for this, I managed to "fix" > my compilation by stubbing out the problematic classes and putting the > stubs ahead of the real classes in the classpath when I compile. Where > those stubs return other objects that are required during static > initialisation, I create those classes with Mockito. I feel dirty all over > but it does work. > > I'm also tinkering with a fork of Clojure in the background that uses ASM > Types instead of Class objects. It's still a long way from done but it's > looking like that might provide a solution for compilation, at least. I'll > report back if I ever get it working. > > > On 15 December 2013 14:05, Colin Fleming <colin.ma...@gmail.com<javascript:> > > wrote: > >> I've just spent some time today looking at the compiler code, and >> unfortunately I think the answer is "no". When a symbol is imported, >> Clojure currently instantiates the Class object using Class.forName() and >> stores that in the namespace's mapping. At the point the Class is >> instantiated, static initializers are run. So the only way to avoid that is >> not instantiate the Class and store something else in the mapping. >> >> Alex's suggestion above to store the string representing the class name >> and load the class on demand might work for REPL style development but >> won't work for AOT compilation since reflection is used to find fields, >> methods etc on the class during compilation. The only solution that I can >> see that would work for AOT would be to store some sort of class wrapper >> object which reads the class bytecode to get that information without >> instantiating the class. >> >> However both of these suggestions break a fairly fundamental assumption - >> that importing a class creates a mapping from its name to a Class object. I >> have no idea what sort of code might be out there making that assumption, >> but it's probably fair to assume there could be a lot of it. At some point >> I might look into creating a fork of Clojure I just use to AOT compile. >> >> >> On 12 December 2013 03:41, Robin Heggelund Hansen >> <skinn...@gmail.com<javascript:> >> > wrote: >> >>> Is this something that is fixable? >>> >>> -- >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com<javascript:> >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com <javascript:> >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com <javascript:>. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >> >> > -- -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
