This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-21
Channels
- # announcements (24)
- # aws (2)
- # babashka (20)
- # beginners (147)
- # cider (20)
- # clara (43)
- # clj-kondo (3)
- # cljdoc (15)
- # cljsjs (1)
- # cljsrn (36)
- # clojars (19)
- # clojure (64)
- # clojure-europe (4)
- # clojure-italy (45)
- # clojure-nl (1)
- # clojure-spec (20)
- # clojure-uk (26)
- # clojurescript (16)
- # cursive (9)
- # datomic (18)
- # dirac (14)
- # docker (3)
- # fulcro (48)
- # keechma (1)
- # leiningen (32)
- # luminus (1)
- # off-topic (40)
- # pedestal (1)
- # quil (1)
- # re-frame (24)
- # reagent (3)
- # reitit (3)
- # remote-jobs (2)
- # ring-swagger (4)
- # shadow-cljs (115)
- # spacemacs (22)
- # specter (4)
- # tools-deps (76)
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 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
in 2.9.0 it looks like bootclasspath use was re-enabled: https://github.com/technomancy/leiningen/releases/tag/2.9.0
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."
@alexmiller what could be done to keep things speedy then?
I don't think it ever really made that much of a difference tbh
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
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)