Clojure Q&A - Recent questions and answers

AVLMap does not implement isEmpty for java.util.Map

Thu, 08 Oct 2026 04:44:14 +0000

The clojure.data.avl AVLMap does not have an implementation for the isEmpty method of the java.util.Map interface.

The cider debugger calls isEmpty on instances of java.util.Map when printing values while stepping through execution. If the value is an AVLMap, this throws an AbstractMethodError that prevents the debugger from working (see the stacktrace below).

I have a workaround, which is to use a :local/root version of clojure.data.avl with isEmpty implemented.

I have not checked if this problem exists on the CLJS implementation.

I am on Clojure 1.12.4 and clojure.data.avl 0.2.1.

  Show: Project-Only All

Hide: Clojure Java REPL Tooling Duplicates (35 frames hidden)

Unhandled java.lang.AbstractMethodError
Method clojure/data/avl/AVLMap.isEmpty()Z is abstract

            avl.clj:   -1  clojure.data.avl.AVLMap/isEmpty
          print.clj:  166  orchard.print/print-map
          print.clj:  165  orchard.print/print-map
          print.clj:  174  orchard.print/eval46055/fn
       MultiFn.java:  234  clojure.lang.MultiFn/invoke
          print.clj:  301  orchard.print/print-str/fn
          print.clj:  301  orchard.print/print-str
          print.clj:  295  orchard.print/print-str
          debug.clj:  195  cider.nrepl.middleware.debug/pr-short
          debug.clj:  183  cider.nrepl.middleware.debug/pr-short
           core.clj: 7059  clojure.core/mapv/fn
      protocols.clj:   42  clojure.core.protocols/iterator-reduce!
      protocols.clj:   52  clojure.core.protocols/iter-reduce
      protocols.clj:   74  clojure.core.protocols/fn
      protocols.clj:   74  clojure.core.protocols/fn
      protocols.clj:   13  clojure.core.protocols/fn/G
           core.clj: 6965  clojure.core/reduce
           core.clj: 7050  clojure.core/mapv
           core.clj: 7050  clojure.core/mapv
           core.clj: 2641  clojure.core/partial/fn
           core.clj: 7059  clojure.core/mapv/fn
      protocols.clj:   42  clojure.core.protocols/iterator-reduce!
      protocols.clj:   52  clojure.core.protocols/iter-reduce
      protocols.clj:   74  clojure.core.protocols/fn
      protocols.clj:   74  clojure.core.protocols/fn
      protocols.clj:   13  clojure.core.protocols/fn/G
           core.clj: 6965  clojure.core/reduce
           core.clj: 7050  clojure.core/mapv
           core.clj: 7050  clojure.core/mapv
          debug.clj:  200  cider.nrepl.middleware.debug/locals-for-message
          debug.clj:  197  cider.nrepl.middleware.debug/locals-for-message
           core.clj: 6259  clojure.core/update
           core.clj: 6251  clojure.core/update
          debug.clj:  244  cider.nrepl.middleware.debug/read-debug-input
          debug.clj:  233  cider.nrepl.middleware.debug/read-debug-input
          debug.clj:  356  cider.nrepl.middleware.debug/read-debug-command
          debug.clj:  322  cider.nrepl.middleware.debug/read-debug-command
          debug.clj:  557  cider.nrepl.middleware.debug/break
          debug.clj:  535  cider.nrepl.middleware.debug/break
           Var.java:  401  clojure.lang.Var/invoke
  DebugSupport.java:   23  cider.nrepl.middleware.DebugSupport/doBreak
               REPL:  749  fredb.index.storage/eval82032/materialize
               REPL:  767  fredb.index.storage/eval82041
               REPL:  767  fredb.index.storage/eval82041
      Compiler.java: 7757  clojure.lang.Compiler/eval

interruptible_eval.clj: 106 nrepl.middleware.interruptible-eval/evaluator/run/fn
interruptible_eval.clj: 101 nrepl.middleware.interruptible-eval/evaluator/run

        session.clj:  251  nrepl.middleware.session/session-exec/session-loop
 SessionThread.java:   21  nrepl.SessionThread/run

Behavior when an alias is defined in multiple deps.edn might be surprising

Sun, 04 Oct 2026 20:42:19 +0000

Situation:

Define the same alias in multiple deps.edn locations—user, project, extra, i.e., via -Sdeps—and then use it in a Clojure CLI invocation.

Behavior:

The definitions of that alias are merged across the four sources.

Why that might be surprising:

Per the CLI deps sources reference "The merge [of the EDN files] is essentially merge-with merge, except for :paths where only the last deps source :paths is used."

In addition, per the CLI deps aliases reference When multiple aliases are provided, the attributes of each alias are merged together under a specific set of rules.

Based on both of these, if you have a single alias defined in multiple sources, you might expect a simple "last definition wins" behavior, since the second part doesn't apply, and the first part indicates :aliases will be simply merge'd across the sources.

However, in tools.deps we see that create-basis takes the EDN maps from all four tiers, gets the :aliases entry from each and does merge-with merge on those.

That's why the alias ends up with a merge of its definitions. I don't think this is documented?

Why does it happen?

I'm not sure, but I suspect this is part of the "aliases are 'just' data" aspect, where a project-level (and extra level) alias can override parts of an "earlier" definition, from other source deps.edn files.

Does it matter?

I ran into this experimenting with the new Clojure CLI REPL project. I added :repl, :serve, and :attach aliases to my user deps.edn and got a warning (about unnamed access) when starting the REPL. I added :jvm-opts to :repl but still got the warning. Later, I added :jvm-opts to :attach so at least connecting a subsequent client didn't get the warning.

Then I noticed that using :repl no longer produced the warning. I looked at the CLI REPL code and it spawns the client at the process level, using clojure and specifying -Sdeps with an alias of :attach to provide the dependencies and :main-opts.

That means that any tooling that runs Clojure processes, expecting to define and then use an alias via -Sdeps can be affected by whatever happens to be in a user's project or user deps.edn file: if the user has the same named alias defined, the tooling gets a merged alias, not just the one it specifies.

int-map: difference ignores its second argument when the first is itself a difference result

Fri, 02 Oct 2026 11:28:00 +0000

(require '[clojure.data.int-map :as i])

(-> (i/int-set [10 1000297])
      (i/difference (i/int-set [10]))        ;=> #{1000297}
      (i/difference (i/int-set [1000297])))  ;=> #{1000297}, expected #{}

When SingleContainer/difference removes its only element, it returns null. IntSet/difference puts that null into the tree instead of dropping the key. In the next difference, the entry with the null value goes to the else branch, which is meant for k1 > k2. That branch moves i2 forward without comparing anything, so the rest of the first set gets copied as is.

Skipping null values from the first set in that loop should fix it. So should not storing empty results in the first place. :)

Answered: Nullpointer exception when using clojure cli with bad deps.edn file

Mon, 21 Sep 2026 00:05:25 +0000

What I get is:

~/tmp/err  $ clj -version
Clojure CLI version 1.12.6.1673
~/tmp/err  $ clj
Error building classpath. Error reading edn. Unmatched delimiter: }  (/Users/alex.miller/tmp/err/deps.edn)

Can you double-check version and update to latest clj if it's old?

Answered: tools.build copy task does not respect non-replaced-exts

Mon, 14 Sep 2026 22:24:38 +0000

Jira created https://clojure.atlassian.net/browse/TBUILD-48

ClojureCLR: case with a boolean-literal branch returns the wrong value when bound to a local

Fri, 11 Sep 2026 17:25:20 +0000

I was working on an project with claude, and found an issue with AOT compilation and unboxing. Here is a summary (generated w/ claude)

A case whose branches are all boolean-typed, with at least one literal true/false, gives wrong results once its value is bound to a local. The same case in tail position is correct.

 (let [f (fn [k x] (case k :a (= 0 x) :b true false))]
   [(f :a 0) (f :a 1) (f :b 0) (f nil 0) (f :zzz 0)])
  ;=> [true false true false false]   ; correct

 (let [f (fn [k x] (let [r (case k :a (= 0 x) :b true false)] r))]
   [(f :a 0) (f :a 1) (f :b 0) (f nil 0) (f :zzz 0)])
  ;=> [true false true true true]     ; the `false` default reads as true

(let [f (fn [k x] (let [r (boolean (case k :a (= 0 x) :b true false))] r))] (f :a 0))
 ;=> InvalidProgramException: Common Language Runtime detected an invalid program.

Reproduces on 1.12.2, 1.12.3-alpha8, and 1.12.6, with keyword, string, and int keys, with let and loop. Branches that are all calls ((= 0 x), (= 1 x)) are fine, as are cond, if, and a fn-call boundary around the case.

What I think is happening, from master: BooleanExpr reports ClrType => typeof(bool) but is not a MaybePrimitiveExpr. CaseExpr unifies its branch types to bool and CanEmitPrimitive only checks that type, so LetExpr declares a bool local and asks the case to emit unboxed. Inside CaseExpr.EmitExpr, the literal branch is not a MaybePrimitiveExpr, so it falls to Emit and pushes a boxed bool onto a stack slot typed bool. The non-null reference reads as true. IfExpr avoids this because its CanEmitPrimitive requires both branches to be MaybePrimitiveExpr.

This looks like the same gap as CLJCLR-151, where David's comment proposes letting BooleanExpr implement MaybePrimitiveExpression. That change would fix this too. A smaller alternative is giving CaseExpr.CanEmitPrimitive the same guard IfExpr has.

Is this already tracked, and should it go on CLJCLR-151 or a new ticket? Happy to write it up in JIRA if useful.

Answered: LRUCache works as FIFOCache when composed with a TTLCache

Wed, 09 Sep 2026 18:36:05 +0000

Created https://clojure.atlassian.net/browse/CCACHE-70

some-> intermediate step suppresses JavaScript extern inference

Mon, 07 Sep 2026 23:32:03 +0000

ClojureScript does not seem to infer an extern or emit an inference warning for a JavaScript method call after an intermediate some-> step.

Advanced compilation then renames the call across an npm boundary and causes a runtime error.

I reproduced this with ClojureScript 1.12.145 and with an uberjar built from master at b45dff9f

Reproduction

deps.edn:

{:deps {org.clojure/clojure {:mvn/version "1.12.4"}
        org.clojure/clojurescript {:mvn/version "1.12.145"}}
 :paths ["src"]}

package.json:

{"dependencies":{"formatter-lib":"file:formatter-lib"},"private":true}

formatter-lib/package.json:

{"main":"index.js","name":"formatter-lib","version":"1.0.0"}

formatter-lib/index.js:

class Formatter {
  constructor(value) {
    this.value = value;
  }

  toPattern(pattern) {
    return `${this.value}:${pattern}`;
  }
}

module.exports = (value) => new Formatter(value);

src/repro/core.cljs:

(ns repro.core
  (:require ["formatter-lib" :as formatter]))

(set! *warn-on-infer* true)

(defn -main []
  (println (some-> (formatter 42) identity (.toPattern "yyyy"))))

(set! *main-cli-fn* -main)

build.edn:

{:infer-externs true
 :install-deps false
 :main repro.core
 :npm-deps {"formatter-lib" "1.0.0"}
 :optimizations :advanced
 :output-dir "target/out"
 :output-to "target/main.js"
 :target :nodejs}

Run:

npm install
clojure -M -m cljs.main -co build.edn -c repro.core
node target/main.js

The compile emits no extern inference warning. The generated call is renamed and Node fails:

TypeError: a.Yb is not a function

The same result occurs with the uberjar built from master:

java -cp /path/to/clojurescript/target/cljs.jar:src \
  clojure.main -m cljs.main -co build.edn -c repro.core
node target/main.js

Control

Removing the intermediate identity step:

(println (some-> (formatter 42) (.toPattern "yyyy")))

causes the compiler to infer the extern:

WARNING: Adding extern to Object for property toPattern due to ambiguous expression

The generated method remains toPattern, and Node prints:

42:yyyy

I expected the version with the intermediate step to infer the same extern, or at least emit a warning that the target type could not be inferred.

Answered: Rose Tree Children Appear to be Eagerly Evaluated (Clojure 1.12+)

Mon, 31 Aug 2026 22:08:55 +0000

What's forcing the child seqs?

Approach to case tableswitch may consume significant bytecode space

Sat, 29 Aug 2026 18:34:55 +0000

The issue:
https://ask.clojure.org/index.php/13407/method-large-compiling-expression-unfortunate-clause-hashes

Logged as:
https://clojure.atlassian.net/browse/CLJ-2808

Possible approaches:
> One approach is to only allow smaller lookup tables.
Another would be to lift the lookup code for large tables into a function or a separate compiled method...

I suggest an approach that just measures a gap between tests.
No need to big span and shift/mask model.
If the gap is less than 128, then we use tableswitch; otherwise, we use lookupswitch.
https://github.com/clojure/clojure/compare/master...magnalium:clojure:dev-2808

Answered: Some core predicates aren't generic over all types

Mon, 24 Aug 2026 14:32:48 +0000

I don't think that we can change the behavior of those predicates since code may rely on the throw. However, docstring updates could help with clarifying what happens when the preds are called with values that might throw.

Bug with installing clojure in OS that isn't in English

Sat, 22 Aug 2026 18:48:24 +0000

I found this bug when trying to install Clojure on my computer that is in Portuguese.
When running the linux-install.sh it was failing silently with -1

I tried to download the tar and do the checksum manually, with this i discovered that the
echo "77dd6868948074adcc93e83a796f8e8f15a1a92bcb1b9002d715fd2210e476f3 clojure-tools-1.12.5.1664.tar.gz" | sha256sum -c
part was printing clojure-tools-1.12.5.1664.tar.gz: SUCESSO, making the grep "^clojure-tools-1.12.5.1664.tar.gz: OK$ fail.

I solved the problem by using LC_ALL=C sudo ./linux-install.sh

Relevant information:
OS: Fedora Linux 44 KDE
Locale: pt_BR.UTF-8

Answered: Why is clojure.core/derive not commutative?

Thu, 06 Aug 2026 14:07:33 +0000

I am falling into this trap as well.

There seems to be a reason for this check?

Answered: tools.reader project file version is outdated

Tue, 04 Aug 2026 13:58:22 +0000

Contrib libraries are built with Maven, not Leiningen. Any project.clj files were added by the individual maintainers, purely for their own convenience, and should not be relied on.

Answered: Concurrency bug in tools.deps use of Aether/Maven libs?

Mon, 27 Jul 2026 22:04:28 +0000

In Clojure CLI 1.12.5.1664 I have moved tools.deps to use a single shared context/system/session instead of creating and caching one per thread. The previous mode was attempting to increase isolation when Maven was handling this poorly. In the newer version of these libs, they have made these interface support concurrency better and I believe this will be better.

Answered: Add assoc-some for constructing maps while skipping nil values

Mon, 27 Jul 2026 13:09:36 +0000

We have an existing jira for this idea at https://clojure.atlassian.net/browse/CLJ-2707

Answered: `(nth nil 10)` returns `nil` when it should throw

Wed, 22 Jul 2026 13:52:32 +0000

This is the expected behvaior (older ticket where this was considered is at https://clojure.atlassian.net/browse/CLJ-2029). nth, like get or contains? has polymorphic behavior on nil, and that is as intended. The docstring could probably be clarified.

JVM-parity bug in how :clojure.datafy/class is set in clojureCLR

Tue, 21 Jul 2026 06:27:09 +0000

As I was working on the magic compiler (the compiler to build to il2cpp in Unity), I noticed i was not having the same behaviour for datafy than clojureCLR.

In fact, we found a small JVM-parity bug in clojure.datafy/datafy, in how :clojure.datafy/class is set in ClojureCLR:

;; JVM clojure (datafy.clj) : fully qualified name, e.g. my.ns.CombinationB
(vary-meta v assoc ::obj x ::class (-> x class .getName symbol))

;; MAGIC's port : .FullName is the CLR equivalent of .getName, so same result
(vary-meta v assoc ::obj x ::class (-> x class .FullName symbol))

;; ClojureCLR (Clojure.Source/clojure/datafy.clj) : .Name is only the short name,
;; e.g. CombinationB, so the namespace is lost
(vary-meta v assoc ::obj x ::class (-> x class .Name symbol))

This breaks code that resolves the class back from the metadata (e.g. reconstructing records from datafied data ). The fix is small change: .Name → .FullName.

Answered: Possible bug in conditional with NaN comparison

Mon, 20 Jul 2026 14:29:43 +0000

It's definitely a bug. Will be fixed in the next release. (I'll have a new alpha out this week, but plan to do a GA release toward the end of the week.)

For those who like details:

It's a bug that only occurs when calling a one of <, <=, >, >= on two arguments in a context where both arguments have known types and the types are both double, and the context of the call is the test in a conditional. So only when we have something like (if (<= ^double x ^double y) ... ). And the generated code gives an incorrect answer only when one or both of the arguments is NaN.

Why? (Asks no one.)

Both the ClojureJVM and ClojureCLR compilers detect calls to numeric comparison operators as the test of a conditional and replace a static method call with an equivalent sequence of direct bytecode/MSIL instructions. The ClojureCLR code copied the comparator code for integer arguments when doing the double, which involved a negation. For integers, the negation of a <= is >. That is not true for doubles, when an argument is NaN. Brain cramp.

Answered: Implement ^:async (CLJS) for protocol functions and multi-methods

Sun, 19 Jul 2026 15:59:04 +0000

As this isn't going to be supported (yet) a workaround that you can use everywhere is:

((^:async fn [] ...your method body here...))

Answered: destructuring with :keys! and :or

Tue, 14 Jul 2026 20:13:00 +0000

Yes, this is as expected.

Note that pre-1.13, :or was a map of binding (unadorned symbol) to default value to be used if a bound key was missing. Any other key type had no meaning and was ignored. In 1.13, :or may contain literal keys that will be added to the :defaults map or be used to fill in the :select map (they have no other use).

1) No :defaults or :select, so :a is just ignored.

2) a is now bound and thus :a is required. Because of this, there is no possibility to use :a from :or in :defaults or :select, so this is now an error.

3) Again, :b is not needed for :defaults or :select, so ignored (really same as #1).

Answered: require yields confusing "namespace ... not found after loading ..." error if masked by empty test file

Tue, 14 Jul 2026 01:43:38 +0000

I realize that I made a mistake, the test file should have been named llm_test.clj instead of llm.clj. Nevertheless the compiler error message could be more user-friendly, perhaps by including the full path to the problematic file.

Answered: Additional handling for `&` symbol in map destructuring for :keys/:syms/:strs could be a breaking change.

Thu, 09 Jul 2026 15:57:10 +0000

Yes, the intent here is to carve this out of being allowed so it is available for syntax purposes in destructuring. We did a fair amount of searching and do not see this being used anywhere.

We've updated the reference page at https://clojure.org/reference/reader#_symbols to explicitly note this.

Browser REPL on different port

Wed, 08 Jul 2026 07:16:39 +0000

Clojurescript's built-in browser REPL is on port 9000 by default but that clashes with ZScaler on my work laptop so I use port 8090 instead. It took a few goes to get it working but now I have it sorted.

clojure -M -m cljs.main -v -p 8090 -co '{:closure-defines {"clojure.browser.repl.PORT" 8090}}' -c foo.core -r

There are some points in the documentation that might benefit from clarification. The -p flag is not mentioned on The REPL and main entry points but seems to serve the same purpose as :port described on REPL Options because this also works:

clojure -M -m cljs.main -v -ro '{:port 8090}' -co '{:closure-defines {"clojure.browser.repl.PORT" 8090}}' -c foo.core -r

What is a little bit surprising is that :port is only mentioned under the Node REPL Options section but applies to browser REPLs too.

Not really a question in all this but I wanted to share this for others who might get stuck.

Versions for posterity: Clojure CLI version (deps.clj) 1.12.2.1565 on Windows 11 and ClojureScript 1.11.54.

Answered: Will :keys! work with nested maps?

Mon, 06 Jul 2026 16:08:02 +0000

If we try that code in a REPL, we see that it complains about :e being missing:

user=> (let [sample-map {:a 1 :b {:a 2 :b 3 :c 4 :d 42}}
             {a :a {aa :a :as m :keys! [b c & d e]} :b} (dissoc sample-map :c)] b)
Execution error (IllegalArgumentException) at user/eval126 (REPL:1).
Missing required key: :e

But the test is weird because sample-map doesn't actually have a :c key at the top level, only nested under :b.

In answer to your overall question, yes, :keys! works anywhere that :keys already works, and that includes nested map destructuring.

Here's an example from our code at work:

  [{:keys! [worldsingles-application members actioner database]
    {:keys! [& redis-pubsub] pubsub :redis-pubsub} :worldsingles-application
    :as service}]

This checks that :redis-pubsub is a key under :worldsingles-application which is a key of service, but does not bind redis-pubsub, and also binds pubsub to the :redis-pubsub key. Yes, we have Alpha 2 in production and this code used to be multiple let bindings and explicit checks for keys being present.

Weird install paths can break linux-install.sh or posix-install.sh scripts

Mon, 06 Jul 2026 15:46:10 +0000

I'm trying to install clojure from the official installer for once, instead of my old "install lein from apt" method -- I wanted the official tool CLIs.

$ curl -L -O https://github.com/clojure/brew-install/releases/latest/download/linux-install.sh
(completes)
$ chmod u+x linux-install.sh 
$ ./linux-install.sh --prefix "$HOME/.local"
Downloading and expanding tar
clojure-tools-1.12.5.1654.tar.gz: OK
Installing libs into /home/fgabolde@/.local/lib/clojure
Installing clojure and clj into /home/fgabolde@/.local/bin
sed: -e expression #1, char 25: unknown option to `s'

Undeterred, I go back to the docs and find a "POSIX" installer. Aha! That must be it. The other installer assumed something about my shell environment and this one must be written to POSIX specs and that will fix everything!

I download posix-installer.sh, do the same dance, and exactly the same happens.

At this point I remember that when this machine was provisioned, IT made a typo and my homedir is /home/fgabolde@ for no good reason. This has tripped up other programs before. And indeed, the sed invocations in the install script use @ as a delimiter, so my weird homedir terminates the replacement string early.

I fixed it by changing the delimiters in the install script and rerunning.

Answered: Namespaced map conversion fails when namespace keyword starts with a number

Mon, 06 Jul 2026 15:27:22 +0000

It looks like Clojure has no problem with either :0 or :0/a

It does, it just doesn't complain - there are very few explicit checks and in general it's GIGO (garbage in, garbage out).

From https://clojure.org/reference/reader:

Symbols begin with a non-numeric character [...] [...]
Keywords are like symbols [...]

Answered: Changing type tags can lead to cryptic errors

Fri, 03 Jul 2026 00:06:18 +0000

It might be useful for the compiler to give a warning when a var is redefined such that it loses a primitive interface.

We could still detect these changes without compiler changes like this:

Clojure 1.12.5
user=> (defn f ^long [^long a] a)
#'user/f
user=> (add-watch #'f ::undo-prim (fn [_ _ old new] (when (and (instance? clojure.lang.IFn$LL old) (not (instance? clojure.lang.IFn$LL new))) (println "WARNING: removed clojure.lang.IFn$LL from f"))))
#'user/f
user=> (defn f [a] a)
WARNING: removed clojure.lang.IFn$LL from f
#'user/f

Possibly avoidable identity call to force instance method on Class literals

Thu, 02 Jul 2026 23:47:10 +0000

As of Clojure 1.13.0-alpha2, (.method ClassName) expands to (.method ^Class (identity ClassName)).

This is to force (.method ClassName) to always be an instance method. Without this, it would expand to (. ClassName method), which may instead be interpreted as a static method.

For example, (.getMethods String) expands to (.getMethods ^Class (identity String)).

This was introduced in these two commits:
- force instance member interpretation of (.method ClassName), e.g. (.getMethods String) works
- added autohinting to Class in macroexpansion of (.instanceMethodOfClass Classname) calls

Since then, Clojure has added support for qualified methods which we can use to reliably propagate the tag without any runtime changes. For example, expanding to (Class/.getMethods String) is now equivalent to (.getMethods ^Class (identity String)) in terms of tag propagation.

I have a proof-of-concept here that includes disassembled and decompiled output before and after the change. The net effect of using qualified methods in this case under direct linking is a removal of a single method call to identity:

   3: invokestatic  #20                 // Method clojure/core$identity.invokeStatic:(Ljava/lang/Object;)Ljava/lang/Object;

The effect is more substantial without direct linking (not included in the PR), with clojure.core/identity also being added to the static initializer.

I've also experimented with expanding to (. (do String) getMethods) (see earlier commits in that PR), which seems to also work and might be another approach.

error printed using pprint in clojure 1.13.0-alpha1

Thu, 02 Jul 2026 20:22:36 +0000

❯ clj -Sdeps '{:deps {org.clojure/clojure {:mvn/version "1.13.0-alpha1"}}}'
Clojure 1.13.0-alpha1
user=> (clojure.pprint/pprint :foo)
Execution error (ClassCastException) at clojure.pprint.proxy$java.io.Writer$IDeref$PrettyFlush$4923d848/flush (REPL:-1).
class clojure.pprint.proxy$java.io.Writer$IDeref$PrettyFlush$4923d848 cannot be cast to class clojure.pprint.PrettyFlush (clojure.pprint.proxy$java.io.Writer$IDeref$PrettyFlush$4923d848 is in unnamed module of loader 'app'; clojure.pprint.PrettyFlush is in unnamed module of loader clojure.lang.DynamicClassLoader @36a58466)
:foo

reported by djblue in #clojure-dev

Syntax-quoted lists can return nil, differs from ClojureScript

Sun, 28 Jun 2026 20:43:55 +0000

Syntax quoted lists can return nil if only empty seqables are spliced into it:

Clojure 1.12.5
user=> `(~@[])
nil
user=> `(~@[] ~@[])
nil

However, the implementation then ensures syntax-quoted empty lists are not nil:

Clojure 1.12.5
user=> `()
()

ClojureScript returns an empty list in these cases:

`(~@[])
=> ()
`(~@[] ~@[])
=> ()

The expansion of syntax quote itself is not necessarily a problem if it differs between platforms, but here the evaluation of the expansion differs. This can cause macros to behave differently between platforms (e.g., JVM Clojure vs bootstrapped cljs).

This behavior seems to be present with all versions of Clojure including 1.0.0, so perhaps the ship has sailed here. I went searching for an existing issue or documentation and AFAICT only CLJ-1425 mentions this oddity.

The reference docs for Syntax Quote also seem to contradict this behavior:

For Lists/Vectors/Sets/Maps, syntax-quote establishes a template of the corresponding data structure.

Answered: how to run a clojurescript repl

Wed, 17 Jun 2026 14:35:29 +0000

This is covered in the QuickStart https://clojurescript.org/guides/quick-start and there is a REPL category under Reference same as clojure.org.

Anything we could do that would make this easier for you to find?

Answered: clj risk of automatic dependency update causing RCE

Tue, 16 Jun 2026 20:30:50 +0000

There is no code execution performed during dependency downloads. So, done.

Answered: Why is aset at least 25 times faster than aset-long?

Mon, 15 Jun 2026 17:05:19 +0000

We’ve spent a bunch of time on this and got into some surprising places with it. I am very much hoping all these set functions will be rewritten in next release.

Answered: Why do literal vectors ignore type hinting?

Sun, 14 Jun 2026 23:09:31 +0000

Literal collections are tagged as IPersistentVector, IPersistentMap, etc and as constant expressions won’t preserve type hints. It is better here to use the new qualified method syntax with param-tags hints if needed.

Consider including a built-in wrapper around `java.net.http.HttpClient` in future versions of Clojure

Mon, 08 Jun 2026 01:37:14 +0000

Java 9 introduced java.net.http.HttpClient[1] with support for HTTP/1.1, HTTP/2 as well as WebSocket along with other features. It was later standardized in Java 11[2] and has become one of the top picks for Java programs. The latest version of the HTTP client shipped with Java 26 also added support for HTTP/3.[3]

It would be nice for future versions of Clojure that are based on Java 11+ to include a new namespace with wrapper functions around java.net.http.HttpClient to make it easier (without all the OOP ceremonies) to work with HTTP in Clojure programs out of the box without relying on any 3rd-party libraries.

Examples of prior art:

[1] https://openjdk.org/jeps/110
[2] https://openjdk.org/jeps/321
[3] https://openjdk.org/jeps/517

Answered: Object.clone() confusion

Sat, 06 Jun 2026 00:06:59 +0000

clone() is a protected method - you should generally not call it on an arbitrary object. In Java, you can't even make that call, you'll get "clone() has protected access in java.lang.Object". It's a quirk of Clojure's impl that it even makes it possible via reflection.

So, my suggestion is to not call clone() at all. There are many, many reasons clone() is problematic and considered one of the more questionable features of Java's early design.

Request: allow a user function to be specified as the target of clojure.main/report-error

Tue, 02 Jun 2026 23:53:32 +0000

The three current targets (file, none, stderr) all serialize all of the error data to a string. During development, it would be convenient to be able to define a function that is called with the exception instance. This function might capture additional application state, or open a window in the user's editor, etc.

Note that it is not possible to work around this by replacing report-error itself because the entire clojure.main namespace is AOT-compiled, so alter-var-root has no effect.

See https://github.com/clojure-emacs/cider/issues/3850 for an example where this feature would be helpful.

Answered: :or destructuring doesn't update object

Mon, 01 Jun 2026 17:45:30 +0000

I logged an improvement request for this here, happy to collect more ideas here.

https://clojure.atlassian.net/browse/CLJ-2957

Answered: `eval` using functions with metadata

Mon, 01 Jun 2026 16:31:28 +0000

You're eval'ing + to a function object there when it seems like you should be staying in symbol land:

user=> (eval (list (with-meta '+ {}) 1 2))
3

A function object itself is not Clojure data (other than opaquely as an object). When working symbolically, you should stay in symbols.

There are some places where the compiler uses an escape hatch of print + read-eval (#=) to recover custom types (sorted maps and sets), but I'd consider that implementation details, not something you as a user should be doing generally.

Answered: Should reduce-kv support String?

Fri, 29 May 2026 21:21:22 +0000

Interesting idea! Logged as https://clojure.atlassian.net/browse/CLJ-2956

Consider allowing passing two arguments to sets used as functions

Tue, 26 May 2026 13:44:16 +0000

Similar to how get works with the 3rd not-found argument.

It already works in CLJS:

ClojureScript 1.12.116
cljs.user=> (#{:a} :b :c)
:c

In Clojure, it errors out:

Clojure 1.12.0
user=> (#{:a} :b :c)
Execution error (ArityException) at user/eval1 (REPL:1).
Wrong number of args (2) passed to: clojure.lang.PersistentHashSet

Answered: gitlibs/tags throws a NPE if the repository has no tags

Sun, 24 May 2026 21:02:21 +0000

Thanks! Fixed in tools.gitlibs 2.6.217.

Answered: The behavior of `filter` on infinite sequences in Transducers

Sun, 24 May 2026 08:31:02 +0000

take converts its collection argument into a seq, and making a seq out of an eduction is done via the java.lang.Iterable route. That route moves the data around in chunks of size 32. So (take ... (eduction ...)) will try to fetch 32 elements regardless of the number passed to take.

So, it's not about transducers, it's about how eduction and converting it into a seq work.

You'll see the same behavior with sequence - but that's because it creates a chunked sequence internally.

Answered: Can 'write-pom' in tools.build support providing additional dependencies in the pom.xml with scope 'provided'?

Thu, 21 May 2026 21:36:50 +0000

tools.build supports :optional true in a dependency, which adds <optional>true</optional> to pom.xml and https://cljdoc.org fetches the dependency, so analysis works, but the dependency does not get pulled in as a transitive dep for "normal" project usage.

See my rephrase project for an example of this working:

https://github.com/seancorfield/rephrase/blob/main/deps.edn#L4-L6

:aliases {:optional {:extra-deps {nrepl/nrepl {:mvn/version "1.7.0" :optional true}}} ...

https://github.com/seancorfield/rephrase/blob/main/build.clj#L34

:basis (b/create-basis {:aliases [:optional]})

(used for the write-pom call)

Doesn't show up when used via deps.edn:

clojure -Spath -Sforce -Sdeps '{:deps {org.corfield/rephrase {:mvn/version "1.0.2"}}}' src:/home/sean/.m2/repository/org/clojure/clojure/1.12.5/clojure-1.12.5.jar:/home/sean/.m2/repository/org/corfield/rephrase/1.0.2/rephrase-1.0.2.jar:/home/sean/.m2/repository/org/clojure/core.specs.alpha/0.4.74/core.specs.alpha-0.4.74.jar:/home/sean/.m2/repository/org/clojure/spec.alpha/0.5.238/spec.alpha-0.5.238.jar

Answered: core.unify does not preserve want-occurs? in recursive unify-variable calls

Tue, 19 May 2026 20:32:36 +0000

Thanks for the report. Definitely not intentional.

Logged at https://clojure.atlassian.net/browse/UNIFY-12

Answered: linux installer fails for non english locale

Tue, 19 May 2026 19:59:16 +0000

Logged as https://clojure.atlassian.net/browse/TDEPS-280, definitely will fix!

Answered: Can clojure builds be reproducible? (new Debian forky requirement)

Tue, 19 May 2026 19:56:55 +0000

Reproducible compilation is not currently a priority for us. But happy to leave this open to hear more reasons why that is important and collect votes.

Answered: `(:k m)` returns `nil` while `(identical? (first (keys m)) :k)` is `true` — two coexisting `Keyword` instances?

Mon, 11 May 2026 16:12:27 +0000

It might also be interesting to know if you are getting a null due to not-found key vs null value in the map. You could supply a not-found arg on (:payload result :NOT-FOUND) to distinguish.

Have you recently updated Clojure?

Is this problem reproducible such that you could try it again with different code, deps, etc?

Keyword invocation uses special call sites and the compiler code for that changed in Clojure 1.12.3, so I would be interested in whether the behavior changes if you use Clojure 1.12.2.

Or alternately, does the behavior change if you modify the code from (:payload result) to (get result :payload).

Answered: Reflection warning when long hint on an argument

Fri, 01 May 2026 21:12:15 +0000

It's the same thing as in https://ask.clojure.org/index.php/13501/primitive-type-hints-arguments-turns-the-return-value-object.