Does anyone know how a Leiningen REPL outside of a project, differs to a Leiningen REPL inside a project? I’m getting an error that occurs only in Leiningen REPLs started outside of a project.

It also occurs in projects that are set to :eval-in-leiningen.

I know they might not use the same version of Clojure

I think outside a project, all deps are the ones lein uses itself, that includes the version of Clojure

The specific problem is in implementing a protocol for java.sql.Timestamp (https://github.com/brandonbloom/fipp/issues/72), so I’m guessing it has something to do with Java’s module system.

that does sound like the module system stuff - may be there is a link within the following that might shed some light on the matter: https://www.deps.co/blog/how-to-upgrade-clojure-projects-to-use-java-9/

java.sql.Timestamp is not in the base module, and leiningen is often started by modifying the bootclasspath, which includes nothing outside the base module

we put a conditional load in for that in Clojure at some point

so using a different clojure version could be triggering that difference

Leiningen shouldn't be modifying the bootclasspath imo as I've said before (and that is outright not allowed in java 14 I believe)

or maybe I'm just thinking of the warning about disabling the verifier

Thanks for the explanation

(Timestamp is used in core for loading #inst formatters and extending the Inst protocol)

so if started in bootclasspath, those things don't get installed

for reference: https://github.com/technomancy/leiningen/pull/2319

in 2.9.0 it looks like bootclasspath use was re-enabled: https://github.com/technomancy/leiningen/releases/tag/2.9.0

so iiuc 2.8.0 through 2.8.3 didn't use the bootclasspath optimization

Java 14 warning: "OpenJDK 64-Bit Server VM warning: Options -Xverify:none and -noverify were deprecated in JDK 13 and will likely be removed in a future release."

fyi

@alexmiller what could be done to keep things speedy then?

or is there no hope

I don't think it ever really made that much of a difference tbh

interesting

clj is faster than leiningen on startup because it (usually) starts only one jvm, not two

that's a bigger factor than the verifier

startup speed is a multi-faceted problem

sure

disabling the security of your jvm is not a good solution imo (esp given that apparently a large percentage of people start their production servers that way)

well, I’m certainly not onboard with disabling any of this in production flows hah

but either way - sounds like perhaps not worth the effort

my 2c -- JVM options hacks are just hacks

nothing going to make startup faster than explicitly designing for fast startup, and going on a classloading diet