Fork me on GitHub
#clojure-dev
<
2018-10-18
>
martinklepsch08:10:36

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?

seancorfield19:10:56

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?

alexmiller20:10:26

re gen-class - you need a build step

seancorfield21:10:05

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

alexmiller20:10:08

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

seancorfield21:10:38

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!

bronsa22:10:34

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

bronsa22:10:07

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

mikerod22:10:41

@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

mikerod22:10:04

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

bronsa22:10:08

dunno, maybe

mikerod22:10:28

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

mikerod22:10:41

but maybe missing other interesting cases

bronsa22:10:56

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

bronsa22:10:53

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

mikerod22:10:54

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

gfredericks22:10:16

proxy can subclass things can't it?