Fork me on GitHub

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 (, 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:

Alex Miller (Clojure team)18:01:40

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

Alex Miller (Clojure team)18:01:12

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

Alex Miller (Clojure team)18:01:28

so using a different clojure version could be triggering that difference

Alex Miller (Clojure team)18:01:20

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

Alex Miller (Clojure team)18:01:00

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


Thanks for the explanation

Alex Miller (Clojure team)19:01:02

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

Alex Miller (Clojure team)19:01:16

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


in 2.9.0 it looks like bootclasspath use was re-enabled:


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

Alex Miller (Clojure team)19:01:18

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."

👀 4

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


or is there no hope

Alex Miller (Clojure team)19:01:10

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



Alex Miller (Clojure team)19:01:53

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

Alex Miller (Clojure team)19:01:23

that's a bigger factor than the verifier

Alex Miller (Clojure team)19:01:02

startup speed is a multi-faceted problem

Alex Miller (Clojure team)20:01:07

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