@bronsa trying to figure out if this me being crazy or if it’s something that should work. Given a namespace:

(ns foo (:import [java.nio.file StandardWatchEventKinds]))
(def a StandardWatchEventKinds/ENTRY_CREATE)

@alexmiller I can't see why that shouldn't work, I'll take a look now

I just tried in a different repl env and it worked … hrm

I wonder if I’m getting java 6 somehow where it’s not available

yeah I'd be very surprised if that didn't work at all -- everything would've been broken then :)

see prior comment re being crazy :)

hmm although if that were the case I'd expect it to fail on the ns

well import doesn’t load now right?

it should still throw on classnotfound

do you still have that broken repl env available?

analyze+ns puts the thrown exception in the returned map as an ExceptionThrown object in the :result key

it might be that an exception did get thrown while evaluating the ns form but analyze+ns just kept on analyzing & failed on analysis of the next form

analyze-ns should probably handle that better

I still have it - I’m in Cursive and I reliably get this

did not see it running lein repl from same project

can you just do something like (->> (try (analyze-ns 'foo) (catch Exception _)) (map :result)))

If I remove the second line, the analyze-ns succeeds

and see if there's an ExceptionThrown in there

or just analyze the first form and see if that has an ExceptionThrown object as its :result

no, nil :result

odd

although ns expands to a do form that explicitly returns nil

so might be buried inside

nah, no errors in there

I think the ns line succeeds

allright I can repro this

aha

this is a funny one

allright, so the exception is getting thrown for the missing namespace

but because ns expands into a do form

the ExceptionThrown object is deep there

t.a.jvm should definitely provide a way of handling this better, I'll have a think about it

but yeah, the error in this case is that your class is not found

still not sure I get how the class is not found in the first place

but I think that’s a cursive question

if you wrap your ns form in like a (let [] ..) you'll get the ExceptionThrown in the top-level map -- it's not there but in a deeper node because of the do unrolling thing

@alexmiller yeah dunno, t.a.jvm uses (RT/makeClassLoader) to get the classloader it uses to analyze/evaluate forms

check (System/getProperty "java.version") maybe?

I know that cursive has to run on java6 for some weird bug in intellij

yeah, I assume that has something to do with it, but I’m not observing that

java 8 classes on the boot classpath etc

I was also able to trigger it by just pulling the import out of the ns

smallest repro case should be (with-bindings {clojure.lang.Compiler/LOADER (clojure.lang.RT/makeClassLoader)} (eval '(import 'java.nio.file.StandardWatchEventKinds)))

if that throws than it's not my fault

if it doesn't then t.a.jvm is somehow doing classloading wrong

it doesn’t throw :)

welp

I'll make a ticket & take a look in the next few days under intellij then

thanks

http://dev.clojure.org/jira/browse/TANAL-120 http://dev.clojure.org/jira/browse/TANAL-121

I’m continuing to try things in both environments and see things that make no sense

I will prob poke at it some more to see if I can make it make sense :)

yeah I'm reasonably sure there's a classloader issue at play there -- I've only ever run t.a.jvm from lein or java -cp and never had those issues, it's possible that cursive does something completely legal with classloaders but that I simply never incurred into & t.a.jvm doesn't handle it

@bronsa @alexmiller Actually only old IntelliJ versions use Java 6 these days - 2016 versions on mandate Java 8.

even weirder then

I don’t do anything very strange with classloaders in the REPL, I can’t see why that would fail or act differently.

Also, the Java 6 thing was for IntelliJ itself, not for user processes - they could always use whichever JVM they wanted.

correctly handling classloading has be one of the most fun things I've had to do /s

yeah, it’s not obvious to me what the difference is

I do definitely see different behavior between the Cursive repl and a lein repl though

I feel like I’m seeing possibly bad state lingering in *env* too maybe?

where once something fails, I get subsequent failures that I do not expect

I will try to isolate it a little better

I am using IntelliJ 2016.3.2 and Cursive 1.4.3

well t.a.jvm fallsback to the mutable namespace system of clojure so if that gets into a bad state so will subsequent calls of analyze-ns

So the funky bit about Cursive REPLs is that I invoke lein in trampoline mode in order to get the REPL classpath. That has caused issues because that’s done in the IntelliJ process, and hence with its JVM. However once the classpath is created, I just run it like any other process and don’t do anything else IIRC. So unless there are some classloader issues causing the REPL classpath to be created incorrectly, I’m not sure what could be going on.

*env* being otherwise tainted should be unlikely given that it gets rebound afresh on every analyze-ns call

the only state there comes from the clojure ns map