Fork me on GitHub
martinklepsch08:10:36 returns dupes when the directory has .clj and .cljc files — it's somewhat conflicting with how require works as far as I understand. Would this be worth a ticket?


I posted this yesterday but didn't get any responses -- anyone care to take a run at it? Just run into something odd... I have a project that uses :gen-class, built with Clojure 1.8 ages ago. I just tried to use it in a Clojure 1.10 (RC1) project and it failed trying to initialize the generated class. This only seemed to happen when I built the JAR via clj and depstar -- when I was building the JAR with boot, it seemed to work. When I dug deeper into it, it seems that in the ns spec, :gen-class now requires :state to be a simple-symbol? -- where it was in fact a string in my old project! I corrected that (re-built the old project with Clojure 1.10 and pushed a new version), then rebuilt my new project's JAR and it seems to work. Yay! So... first question, if I'm using code with :gen-class which requires AOT, what is the right way to handle that in the clj / deps.edn world now? Second question, does my line of reasoning sound right, that attempting to load a class generated from an ns with a bad :gen-class clause would fail at runtime, even tho' the namespace (and the generated .class file) were previously compiled and both available on the classpath?

Alex Miller (Clojure team)20:10:26

re gen-class - you need a build step


OK, so as simple as running (compile 'some.ns) as long as you have a classes folder on your classpath I guess...

Alex Miller (Clojure team)20:10:08

on the 2nd question, don’t know without doing a lot of work


NP. I'm going to assume my logic is right -- it was just very hard to track down why it was failing to "initialize" the class because the actual cause was masked. I may try to create a simple repro case an open a ticket -- it would be nice if the exception was more informative!


FYI I never quite understood the rationale for gen-class requiring AOT, ther doesn't seem to be a technical reason why it couldn't JIT


I'm wondering if the reason is not historical due to how the classloader worked pre CLJ-979, as it was for e.g. gen-interface


@bronsa I was thinking that it was due to the primary use-case for gen-class was to have a more “static” classfile on the classpath for a lang like Java to compile against with something like javac


I’m not sure what usage it would have for a scenario using JIT


dunno, maybe


I know the only reason I have used it has been for Java compile-time interop


but maybe missing other interesting cases


I have only used it to subclass Exception and that was really painful


I guess I'm ok with it being not that useful, if it means I won't see many usages of it in the wild :)


yeah, subclassing things too, I guess there are cases for that that would be fine JIT


proxy can subclass things can't it?