clojure.tools.namespace.find/find-sources-in-dir 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?

https://dev.clojure.org/jira/browse/TNS-42 related at least

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?

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

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 :)

hah

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

proxy can subclass things can't it?