Clojure Q&A - Recent activity

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

Tue, 12 May 2026 06:06:08 +0000

Thank you for the response, Alex — really appreciate it.

Clojure upgrade:
We jumped from Clojure 1.11.1 to 1.12.4 on 2025-12-22. Same commit also moved us from JDK 17 to JDK 25 with virtual threads. The bug investigation started around March 2026, so there's roughly a 2 month gap between the upgrade and our first reports though it's possible the bug existed earlier and went unnoticed.

Reproducibility:
Not manually. But we see this happening about 1 to 3 times a week. We have 10 instances running and handling roughly the same amount of workload, but the bug suddenly starts on one of the instances and then doesn't stop. We haven't been able to identify any patterns. It seems quite random.

Experiments we will try:
1. (:payload result :NOT-FOUND)
2. (get result :payload) vs (:payload result)

Since the bug isn't manually reproducible and nREPL recompile fixes it for the affected instance, each experiment needs a new release, and a probabilistic waiting window of ~1 week before we can claim a result with any confidence. We will do both the experiments above in a single release.

Depending on the results from the first two experiments, we will also consider downgrading Clojure to 1.12.2 and seeing if that fixes the issue.

Question:
Given that your hypothesis points at the keyword call-site compilation rather than at duplicate interned instances, would logging `System/identityHashCode` of the :payload literal and payload-key still be a useful diagnostic to add? Or does the call-site explanation make it largely irrelevant?

I'll report back as soon as we have signal — likely within a week. Thank you again.

Answer selected: Reflection warning when long hint on an argument

Fri, 08 May 2026 10:11:04 +0000

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

Comment edited: Do primitive type hints in fn arguments turns the return value as an Object?

Sat, 02 May 2026 11:07:04 +0000

Indeed @alexmiller, it seems the same issue as https://ask.clojure.org/index.php/15067/reflection-warning-when-long-hint-on-an-argument

Was there any reason why this didn't go forward? Is it more involved than a simple bugfix? Asking because I cannot see the ticket.

Commented: Default implementation of AsElements to treat numbers as numbers, not strings

Thu, 30 Apr 2026 12:28:22 +0000

That was my first reaction as well. Seems like content should generally be considered as a string, so maybe it's the xml/element constructor doing the wrong thing here.

Commented: Porting .NET 4.8 application using Clojure CLR to .NET 8

Wed, 29 Apr 2026 02:52:51 +0000

System.Text.Json comes in only as a transitive dependency. Not sure what other libs require it -- could be several. Installed version is 10.0.7. Could be a version issue? Not sure how to even figure these things out in your scenario. (I had to do some serious tweaking to get all the right libraries in place for my little C++ console app.)

Commented: Installing Clojure on IPv6-only machine

Sat, 25 Apr 2026 01:16:16 +0000

Yeah, between Maven's regular repo URL and Clojars and GitHub all not offering IPv6, I don't know how far you're going to get.

Commented: Does Clojure have an anti LLM code contributions policy? Would it make sense for Clojure to adopt one?

Mon, 13 Apr 2026 14:53:13 +0000

I think "Code generated by a large language model ..." would include LLM auto complete.

Commented: Allow multiple bindings for if-let, when-let, if-some, and when-some

Thu, 09 Apr 2026 22:03:01 +0000

I would like to improve Issue 2213 as follows. Do you think, this makes sense?

The new description would be:

When developing Input-Process-Output tools I am often in the situation, that I have a sequence of activities (e.g. opening a file, spec checking a file, calling external tools, creating files), which each could fail in certain ways. Clojure does not have a good way to control such a sequence of activities in a way that all sorts of things, which could go wrong, can be handled comfortably. In imperative programming languages concepts like early exit or bailout are used. These are not not very functional. Unfortunately practical problems are often like this.

The issue is a bit more general and a solution would be nice not only for those who develop such sort of tools. So I can give a simple example.

(let [config-file (get-file-from-network xy)
      config-file (parse-edn config-file)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

As all these steps can fail, we could instead implement it like this.

(if-let [config-file (get-file-from-network xy)]
  (if-let [config-file (parse-edn config-file)]
    (if (spec-check config-file)
      (do-something-with config-file))))

Now the code has suffered already a lot. The sequential nature of the problem is lost. And it is not even doing what we need. We have to report to the user what went wrong.

(if-let [config-file (get-file-from-network xy)]
  (if-let [config-file (parse-edn config-file)]
    (if (spec-check config-file)
      (do-something-with config-file)
      :file-has-syntax-errors)
    :file-not-valid-edn)
  :file-cannot be openned)

But this is still not doing what we need. We have to provide more information about each failure. If a file cannot be openned, is it because the file does not exist or we do not have read permissions? And what did the spec check tell us? So we cannot just use nil as a universal failure. We must deliver more information when failing. And we cannot use if-let, either. So we are not even done.

This problem report asks for a better solution for this conceptual challenge.

This example depicts a conflict that should not happen when using an appropriate programming language: First we are able to quickly make a prototype. But in the end the final code has not much in common with the first code any more. The final design is not driven by the problem domain, but by the technical need for an error handling. The need for a bailout mechanism in this example imposes too many huge code changes.

The principal problem with all these solutions is that they coerce a sequence of actions into something which is not a sequence. If your problem is a sequence, then the implementation should also be a sequence.
Idea: Exceptions

As an alternative implementation I went with Exceptions. But it feels wrong, because I am talking about things, that are expected to fail. I cannot just use the Exceptions that are comming out of Java for example when opening a file for read. I need detailed information, what went wrong. If you are a command line tool, it is expected from you, that you provide good error messages. I ended up catching and rethrowing exceptions everywhere in the program.
Idea: Like for/doseq

For me I created a small macro, that extends let. Then I use this syntax:

(let [[config-file error] (get-file-from-network xy)
      :escape     error
      config-file (parse-edn config-file)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

This often allows a surprisingly intuitive code. For example here:

(let [[config-file error-code] (get-file-from-network xy)
      :escape     (if (= error-code :does-not-exist)
                    :file-xy-does-not-exist)
      :escape     (if (= error-code :io-error)
                    :file-xy-cannot-be-read)
      [config-file error-code] (parse-edn config-file)
      :escape     (if error-code :file-xy-not-legal-edn)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

This is inspired by the for/doseq. But I don't claim that this is a good solution for Clojure (although I think so). But I think, the let macro is a good candidate when improving how Clojure can be used for such imperative things.
Idea: Using if-let

I also investigated the solution, that was originally proposed by this issue.

(if-let [config-file (get-file-from-network xy)
         config-file (parse-edn config-file)
         config-file-ok? (spec-check config-file)]
  (do-something-with config-file)
  :error)

This problem with this solution is that none of the bindings are available in the else part. That makes it very hard to react accordingly. This is a nice and small new language feature. But I don't think, that in practice it would be of help so often. The example from the original issue was very artificial with mathematical operations that cannot fail. The first draft of this issue with that artificial example does not actally describe a real problem. That is why this issue has completelly been rewritten.

Or course we could still bind everything, which was not failed. But I don't think, we would want that. It would have very interesting consequences to the compiling model.
Idea: Threading macros

As this issue is a about a sequence of activities, a new type of threading macro (e.g. let->) could also be an intuitive solution. But I have not tried anything like this.
Final Words

The principle challenge is, that all these solutions establish a sort of alternative control flow. It is a hard challenge to do this right, especially in a functional language. Like exceptions, that immediatelly exit and magically jump somewhere else. Clojure as a practically language could address this challenge.

Commented: Cannot resolve public generic method from package-private base class

Wed, 08 Apr 2026 21:37:42 +0000

I hit this with Google’s [mug](https://github.com/google/mug) library. The [format method](https://google.github.io/mug/apidocs/com/google/mu/util/StringFormat.html#format(java.lang.Object,java.lang.Object)) is declared as public final on AbstractStringFormat, which is package-private. StringFormat is public and [inherits](https://github.com/google/mug/blob/master/mug/src/main/java/com/google/mu/util/StringFormat.java#L86) it.

In Java this works fine — javac emits invokevirtual on the public subclass. In Clojure, all three interop paths fail:

1. *Type-hinted call* `(.format ^StringFormat fmt "a" "b")` -> No matching method format found taking 2 args
2. *Method reference* `^[Object Object] StringFormat/.format` -> IllegalAccessError: failed to access class AbstractStringFormat
3. *No type hint (reflection)* `(.format fmt "a" "b")` -> same as #1

`java.lang.reflect.Method` works fine — `StringFormat.class.getMethod("format", Object, Object)` finds and invokes it without issues.

This looks like [CLJ-1243](https://clojure.atlassian.net/browse/CLJ-1243) (open since 2013).

#!/bin/sh
#_(
DEPS='{:deps {com.google.mug/mug {:mvn/version "9.9.9"}}}'
exec clojure -Sdeps "$DEPS" -M "$0" "$@"
)

;; https://clojure.atlassian.net/browse/CLJ-1243

(import '(com.google.mu.util StringFormat))

(def fmt (StringFormat. "{a}/{b}"))

(println "=== 1 ===")
(try
  (eval '(.format ^StringFormat fmt "a" "b"))
  (catch Throwable e
    (println (str " " (.getClass e) ": " (.getMessage e)))))

(println "=== 2 ===")
(try
  (eval '(let [f ^[Object Object] StringFormat/.format]
           (f fmt "a" "b")))
  (catch Throwable e
    (println (str " " (.getClass e) ": " (.getMessage (or (.getCause e) e))))))

(println)
(println "=== 3 ===")
(try
  (let [result (.format fmt "a" "b")]
    (println (str " result: " result)))
  (catch Throwable e
    (println (str " " (.getClass e) ": " (.getMessage e)))))

(println)
(println "=== 4 ===")
(let [m (-> StringFormat (.getMethod "format" (into-array Class [Object Object])))]
  (.setAccessible m true)
  (println (str " result: " (.invoke m fmt (object-array ["a" "b"])))))

Closed: Unroll constantly to improve performance of multi-arity calls

Tue, 07 Apr 2026 21:25:53 +0000

This was found to be a hot spot when testing some Specter use cases.

Review of common uses of constantly shows that the arity 1 case is the most common use of `constantly` in the wild, so only unrolled to two arguments.

Perf test:

(use 'criterium.core)
(def f (constantly 1))
(bench (dotimes [_ 1000] (f)))
(bench (dotimes [_ 1000] (f 1)))
(bench (dotimes [_ 1000] (f 1 2)))

;; Results:
;; Arity Before         After
;; 0     611.455589 ns 607.800747 ns    (no change was expected)
;; 1     3.098828 µs    611.116510 ns    (~5x improvement)
;; 2     3.508726 µs    620.415032 ns    (~5x improvement)

*Patch:* 0001-CLJ-2228-Improve-performance-of-constantly.patch

*Prescreened by:* Alex Miller

Commented: "Nested" vs "lateral" exception causes

Tue, 07 Apr 2026 16:04:04 +0000

I guess I don't follow your argument about LazyTest. For something to have a "list of exceptions", then it has already caught and accumulated all of those exceptions in a Clojure data structure -- so once it is "done", it could just (throw (ex-info "failures" {:causes list-of-caught-exes})) -- that data-conveyance is exactly what ex-info is intended for.

All exceptions in Java-land (including ex-info's ExceptionInfo) have .getCause as a method and Clojure's ex-cause is "just" a wrapper around that (that works across dialects too: ClojureScript's API and behavior here is essentially identical to Clojure's, just mapped to JS).

The work in dealing with the "list of exceptions" is in the domain-specific part of the code here: something has to catch & accumulate in a way that is appropriate for the domain.

Closed: Is the recent change to flow's futurize safe?

Mon, 06 Apr 2026 21:24:03 +0000

Previously flow's futurize would rethrow any exceptions thrown by the function when deref'ed. With the recent changes to return a CompletableFuture it no longer does that and instead if the function throws deref'ing will just hang forever.

Answered: Optimize `eduction`

Sun, 05 Apr 2026 21:50:04 +0000

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

Edited: Destructuring {:as opts} unexpected behaviour with seq

Sun, 05 Apr 2026 09:19:47 +0000

Hi,

I found out something weird in some old code, where I wanted to pass the first map in a sequence and by mistake the code was working while actually passing the sequence itself!

After digging to make sense of this, I found out it has to do with the {:as opts} destructuring.

Here's some code:

;; even if something is assigned sequential vs associative
;; the `:as` is transparent
(let [[:as opts] {1 2 3 4}]
  opts)
#_=> {1 2, 3 4}
(let [{:as opts} [1 2 3 4]]
  opts)
#_=> [1 2 3 4]
;; however with a seq it's returned as a map
(let [{:as opts} (seq [1 2 3 4])]
  opts)
#_=> {1 2, 3 4}

;; and it only gets weirder!
(let [{:as opts} (seq [{:k :v}])]
  opts)
#_=> {:k :v}
(let [{:as opts} (seq [{:k1 :v1} {:k2 :v2}])]
  opts)
#_=> {{:k1 :v1} {:k2 :v2}}
(let [{:as opts} (seq [{:k1 :v1} {:k2 :v2} {:k3 :v3}])]
  opts)
#_=> {{:k1 :v1} {:k2 :v2}, :k3 :v3}
(let [{:as opts} (seq [{:k1 :v1} {:k2 :v2} :not-a-map])]
  opts)
;; java.lang.IllegalArgumentException: Don't know how to create ISeq from: clojure.lang.Keyword
(let [{:as opts} (seq [1 2 3])]
  opts)
;; java.lang.IllegalArgumentException: Don't know how to create ISeq from: java.lang.Long

In my case I didn't realize my code was wrong because {:as opts} {:k :v} is the same as {:as opts} (seq [{:k :v}]).

To me this is behaviour I would expect closer to & {:as opts} rather than just plain map destructuring {:as opts}. Maybe both behaviours should be separated?

I think this should be tackled either by
1. make :as transparent regardless of what comes in to always bind
2. throw an error earlier when it's not of the expected destructuring
3. Document this very unexpected edge case in https://clojure.org/reference/special_forms#associative-destructuring
4. Separate the keyword arguments use case from plain map destructuring? (Assuming both are now mixed together)

Edited: Missing protocol error will hang on infinite `(range)` input in ClojureScript but not Clojure

Fri, 03 Apr 2026 11:22:38 +0000

functions like transient, assoc, etc will throw helpful missing-protocol error when receiving invalid input but it will hang if it receives infinite (range).
this is related to issue below
https://ask.clojure.org/index.php/14578/even-range-hangs?show=14578#q14578

however, missing-protocol only hang in clojurescript but not clojure so I am wondering if this difference is intended.

example calls that should throws
- (transient (range))
- (assoc (range) :a 1)

Commented: How to fix error 'could not acquire write lock for 'artifact:org.bytedeco:opencv:4.5.5-1.5.7' ?

Fri, 03 Apr 2026 09:52:20 +0000

GitHub agents are a good spot to see the problem, as they start with an "empty" .m2 folder.
If here:
https://github.com/scicloj/metamorph.ml/blob/14b4e609a18ec9b291bc26a160108d249e56ba70/.github/workflows/main.yml#L50

I would remove here the "-Sthreads 1", the build would (I believe) fail on each run.

Answered: requiring an empty .clj without an alias should fail as with an alias

Thu, 02 Apr 2026 20:41:10 +0000

Logged:
https://clojure.atlassian.net/browse/CLJ-2951

And one for compile:
https://clojure.atlassian.net/browse/CLJ-2952

Commented: Is taggedliteral's equality check inefficient?

Wed, 01 Apr 2026 17:31:34 +0000

Uploaded a patch

Closed: Controlled Bailout, Jira issue 2213

Tue, 31 Mar 2026 19:54:30 +0000

I would like to improve Issue 2213 as follows. Do you think, this makes sense? Shall I become contributor for this?

The new description would be:

When developing Input-Process-Output tools I am often in the situation, that I have a sequence of activities (e.g. opening a file, spec checking a file, calling external tools, creating files), which each could fail in certain ways. Clojure does not have a good way to control such a sequence of activities in a way that all sorts of things, which could go wrong, can be handled comfortably. In imperative programming languages concepts like early exit or bailout are used. These are not not very functional. Unfortunately practical problems are often like this.

The issue is a bit more general and a solution would be nice not only for those who develop such sort of tools. So I can give a simple example.

(let [config-file (get-file-from-network xy)
      config-file (parse-edn config-file)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

As all these steps can fail, we could instead implement it like this.

(if-let [config-file (get-file-from-network xy)]
  (if-let [config-file (parse-edn config-file)]
    (if (spec-check config-file)
      (do-something-with config-file))))

Now the code has suffered already a lot. The sequential nature of the problem is lost. And it is not even doing what we need. We have to report to the user what went wrong.

(if-let [config-file (get-file-from-network xy)]
  (if-let [config-file (parse-edn config-file)]
    (if (spec-check config-file)
      (do-something-with config-file)
      :file-has-syntax-errors)
    :file-not-valid-edn)
  :file-cannot be openned)

But this is still not doing what we need. We have to provide more information about each failure. If a file cannot be openned, is it because the file does not exist or we do not have read permissions? And what did the spec check tell us? So we cannot just use nil as a universal failure. We must deliver more information when failing. And we cannot use if-let, either. So we are not even done.

This problem report asks for a better solution for this conceptual challenge.

This example depicts a conflict that should not happen when using an appropriate programming language: First we are able to quickly make a prototype. But in the end the final code has not much in common with the first code any more. The final design is not driven by the problem domain, but by the technical need for an error handling. The need for a bailout mechanism in this example imposes too many huge code changes.

The principal problem with all these solutions is that they coerce a sequence of actions into something which is not a sequence. If your problem is a sequence, then the implementation should also be a sequence.

Idea: Exceptions

As an alternative implementation I went with Exceptions. But it feels wrong, because I am talking about things, that are expected to fail. I cannot just use the Exceptions that are comming out of Java for example when opening a file for read. I need detailed information, what went wrong. If you are a command line tool, it is expected from you, that you provide good error messages. I ended up catching and rethrowing exceptions everywhere in the program.

Idea: Like for/doseq

For me I created a small macro, that extends let. Then I use this syntax:

(let [[config-file error] (get-file-from-network xy)
      :escape     error
      config-file (parse-edn config-file)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

This often allows a surprisingly intuitive code. For example here:

(let [[config-file error-code] (get-file-from-network xy)
      :escape     (if (= error-code :does-not-exist) 
                    :file-xy-does-not-exist)
      :escape     (if (= error-code :io-error)
                    :file-xy-cannot-be-read)
      [config-file error-code] (parse-edn config-file)
      :escape     (if error-code :file-xy-not-legal-edn)
      syntax-ok?   (spec-check config-file)]
  (do-something-with config-file))

This is inspired by the for/doseq. But I don't claim that this is a good solution for Clojure (although I think so). But I think, the let macro is a good candidate when improving how Clojure can be used for such imperative things.

Idea: Using `if-let`

I also investigated the solution, that was originally proposed by this issue.

(if-let [config-file (get-file-from-network xy)
         config-file (parse-edn config-file)
         config-file-ok? (spec-check config-file)]
  (do-something-with config-file)
  :error)

This problem with this solution is that none of the bindings are available in the else part. That makes it very hard to react accordingly. This is a nice and small new language feature. But I don't think, that in practice it would be of help so often. The example from the original issue was very artificial with mathematical operations that cannot fail. The first draft of this issue with that artificial example does not actally describe a real problem. That is why this issue has completelly been rewritten.

Or course we could still bind everything, which was not failed. But I don't think, we would want that. It would have very interesting consequences to the compiling model.

Idea: Threading macros

As this issue is a about a sequence of activities, a new type of threading macro (e.g. let->) could also be an intuitive solution. But I have not tried anything like this.

Final Words

The principle challenge is, that all these solutions establish a sort of alternative control flow. It is a hard challenge to do this right, especially in a functional language. Like exceptions, that immediatelly exit and magically jump somewhere else. Clojure as a practically language could address this challenge.

Answered: Optimized str function

Sun, 29 Mar 2026 08:47:19 +0000

I've done some independent exploration of the options space for optimizing str which does not involve anything ground shattering but still gives good performance improvements

variadic arities (up to 20, yuck) will probably give the best performance. Can settle for common cases like up to 5 (apply str will still suck but whatever)
using reduce instead of a loop (would probably require redefining str or providing a str1 with the old impl for bootstrap purposes)
using inline meta, orthogonal to all other options

Additionally, having a function like str which only takes a sequence and reduces over it could provide a better code path than (apply str xs)

Similar work has been done in spork and stringer

Closed: Why doesn't defn also implicitly name the anonymous function it defines for recursion?

Thu, 26 Mar 2026 17:24:24 +0000

Why doesn't defn implicitly name the function to create a named recursion point?

(clojure.walk/macroexpand-all
  '(defn foo [x]
     (foo x)))
; =>
(def foo
  (fn*
    ([x]
     (foo x))))

This could instead expand to

(def foo
  (fn* foo ; note the foo here
    ([x]
     (foo x))))

How it works right now, foo resolves to a global var #'foo, which is created when the (def ...) form is analyzed. In the second case, it resolves directly to the function object. Thus, it should save us a var dereference at runtime in this case.

EDIT: Found out, this is exactly what direct linking is used for.

Edited: Evaluating forms using eval can create a valid undesirable recursion point

Thu, 26 Mar 2026 04:05:02 +0000

When the eval function in Clojure is called with an argument that is an instance of IPersistentCollection which likely isn't a special def-like form (the first element isn't a symbol at all or it does not start with "def"), the form is first wrapped in an anonymous function which then gets compiled and invoked, which indirectly evaluates the original form.

There aren't any extra checks performed and it makes forms like these 2 valid, which should normally be rejected and a compiler exception should be thrown:

(recur)

(let []
  (print "Hello")
  (Thread/sleep 1000)
  (recur))

where the 2nd form keeps printing "Hello" and loops infinitely over the outer wrapper function.

Comment edited: shasum not found error when using ./posix-install on linux

Thu, 12 Mar 2026 00:09:15 +0000

from https://clojure.org/guides/install_clojure

> This installer should work on Linux, BSD, and even Mac (but will conflict with brew!)

That made me think that I should expect the posix installer to work.

Answer selected: clojure.core.cache caches delays that hold exceptions as of version 1.2.254

Wed, 11 Mar 2026 18:21:37 +0000

Version 1.2.263 solves both the cache stampede bug and the cached exceptions bug, and does so without locking. Thank you, Claude Opus 4.6.

Closed: tools.cli: capture unrecognized options as unparsed arguments

Tue, 10 Mar 2026 16:08:38 +0000

I frequently write a command that accepts options and in turn execute a shell command passing arguments through; I want to be able to specify additional arguments to that shell command.

In tools.cli, the :in-order key almost does what i want:

`
(require '[clojure.tools.cli :as cli])
=> nil
(def opts [["-d" "--debug"]])
=> #'net.lewisship.cli-tools-test/opts
(cli/parse-opts

["--foo"]
[]
:in-order true)

=> {:options {}, :arguments [], :summary "", :errors ["Unknown option: \"--foo\""]}
(cli/parse-opts

["xxx" "--foo"]
[]
:in-order true)

=> {:options {}, :arguments ["xxx" "--foo"], :summary "", :errors nil}
`

However, it will assume an undefined option is an error until the first non-option argument is consumed.

I would like a further option that is like :in-order but accepting of these unrecognized options. Maybe, :passthru-options would be a good name?

I can work on a patch if we have some consensus on direction.

Closed: Review cli-matic for inspiration for enhancing tools.cli

Fri, 06 Mar 2026 01:06:24 +0000

See https://cljdoc.org/d/cli-matic/cli-matic/0.2.7/doc/readme

Closed: Tools.cli :validate: provide a way to post-validate (after updates)

Fri, 06 Mar 2026 01:05:21 +0000

aratare on Slack had this code:

["-v" nil "Verbosity level; may be specified up to 2 times. Levels: INFO (Default) -> DEBUG -> TRACE"
    ;; If no long-option is specified, an option :id must be given
    :id :min-level
    :default 0
    :update-fn inc
    :validate [(fn [a]
                 (println a)
                 (<= a 2)) "Verbosity level cannot exceed 2."]]

and asked:

and a is printed as true instead of either the level before or after applying update-fn. Is there a way to work around this so I can validate after update-fn has been called? Thanks in advance. (edited)

Closed: Tools.cli :validate: provide function of invalid value in addition to fixed string

Fri, 06 Mar 2026 01:04:56 +0000

The :validate option currently takes a validation function and a string error message.

Could we extend the second argument to a function instead so you can return an error message like "--foo should be greater than 10, but was: 11.

We could even plug clojure.spec.alpha or malli in there:

(def cli-options
  [["-n" "--number NUM" "A number"
    :parse-fn (m/decoder int? mt/string-transformer)
    :validate [(fn [input]
                 (m/validate [:< 100] input))
               (fn [input]
                 (me/humanize (m/explain [:< 100] input)))]]])

Closed: tools.cli: display default value for --[no-]foo flags in help summary

Fri, 06 Mar 2026 01:04:34 +0000

Salut

While boolean options of the form "--foo" are false by default and enabled by specifying them, flag options of the form "--[no-]foo" accept "--foo" and "--no-foo" to toggle them on or off respectively. The default could be true or false, but the user has no way to tell what the default value is based on the help summary.

For those options I think it is helpful (even necessary) to always display the default value, whether the option is required or not.

I've drafted a patch that could serve as a starting point.

A related thought: shouldn't the default always be shown, even if it isn't a required option? Maybe there is a good reason for this, but I don't get why non-required options hide their default in the help summary.

Thanks for your work!

Closed: Compile parser ahead of time

Fri, 06 Mar 2026 01:03:57 +0000

tools.cli/parse-opts accepts the args, the option-spec, and the additional options. It calls compile-option-specs and required-arguments to build the specs and req. Then it performs the validation with those specs and req on the provided args (along with the options). For a given application, the first two steps aren't going to change across calls.

I propose a new make-parse-opts-fn function that performs the compile-option-specs and required-arguments up front and returns a function that relies on the compiled specs and req. It could be used like this: (def compiled-parser (make-parse-opts-fn cli-options)).

Microbenchmarking with criterium shows a more than double increase in speed (tools.cli/parse-opts first, pre-compiled parser second):

; user=> (def cli-options
  [["-h" "--help" "This message"]
   [nil "--extra" "Output in extra format"
    :default false]
   ["-q" "--quiet" "Print no suggestions, only return exit code"
    :default false]])
#'user/cli-options

; user=> (bench (cli/parse-opts ["--quiet" "src"] cli-options :in-order true))
Evaluation count : 10962 in 6 samples of 1827 calls.
             Execution time mean : 65.021329 µs
    Execution time std-deviation : 5.276033 µs
   Execution time lower quantile : 58.658638 µs ( 2.5%)
   Execution time upper quantile : 69.724228 µs (97.5%)
                   Overhead used : 9.607933 ns
nil

; user=> (bench (compiled-parser ["--quiet" "src"] :in-order true))
Evaluation count : 24660 in 6 samples of 4110 calls.
             Execution time mean : 25.090846 µs
    Execution time std-deviation : 253.361821 ns
   Execution time lower quantile : 24.769079 µs ( 2.5%)
   Execution time upper quantile : 25.413286 µs (97.5%)
                   Overhead used : 9.607933 ns
nil

If the additional options are lifted into the make-parse-opts-fn as well (trading flexibility for speed), the difference is even more dramatic, providing roughly 10x speed increase over the existing tools.cli/parse-opts function:

; user=> (bench (compiled-parser-2 ["--quiet" "src"]))
Evaluation count : 73116 in 6 samples of 12186 calls.
             Execution time mean : 8.349923 µs
    Execution time std-deviation : 51.419864 ns
   Execution time lower quantile : 8.282266 µs ( 2.5%)
   Execution time upper quantile : 8.407998 µs (97.5%)
                   Overhead used : 9.607933 ns

Found 2 outliers in 6 samples (33.3333 %)
	low-severe	 1 (16.6667 %)
	low-mild	 1 (16.6667 %)
 Variance from outliers : 13.8889 % Variance is moderately inflated by outliers
nil

I can provide a patch for this if there's interest.

Closed: Providing nil for long option in tools.cli does not seem to work per readme

Fri, 06 Mar 2026 01:01:11 +0000

Hi,

A very simplified tools.cli call:

(let [cli-opts [["-m" "--mode MODE" "Application mode"]]]
  (cli/parse-opts ["-m" "hub"] cli-opts))

Evaluates as expected to:

{:options {:mode "hub"} ... }

However, when I try to replace the long option with nil per the docs:

(let [cli-opts [["-m" nil "Application mode" :id :mode]]]
  (cli/parse-opts ["-m" "hub"] cli-opts))

I get:

{:options {:mode true} :arguments ["hub"] ... }

I get the same behaviour with long option = "", "--mode", and "MODE"; the only way it seems to work is with the full "--mode MODE". Setting the short option to nil works as I'd expect.

Tested in Clojure 1.12.0, tools.cli 1.1.230, Java 23; same behaviour on Windows 11 and MacOS 15.

Am I doing something wrong, or is tools.cli? :)

Closed: Incorrect docstring for parse-opts

Fri, 06 Mar 2026 01:00:43 +0000

In the docstring for clojure.tools.cli/parse-opts (seen here), it says,

:id           The key for this option in the resulting option map. This
              is normally set to the keywordized name of the long option
              without the leading dashes.

              Multiple option entries can share the same :id in order to
              transform a value in different ways, but only one of these
              option entries may contain a :default(-fn) entry.

              This option is mandatory.

The final line says "This option is mandatory." which is technically true for parse-opts' internals, but it's not true for users because (as the first paragraph says) :id is also generated by keywordizing the long option.

May I recommend changing it to be more explicit? Something like "If a long option is not provided, this option is mandatory."

Answer selected: It's difficult to figure out options I can pass to slurp function.

Sat, 28 Feb 2026 06:27:25 +0000

This is fair. I created https://clojure.atlassian.net/browse/CLJ-2944 to track this.

Closed: Could some calls to clojure.core/= be replaced by clojure.core/identical?

Thu, 26 Feb 2026 17:09:09 +0000

I'm using core.cache in combination with LazyMap. Lazy maps are map-like objects (new data type encapsulating maps and adding some logic to auto-force delayed values associated with keys).

When I started putting lazy maps as values of FIFO Cache I observed that all values are being realized just after the map lands in cache. After some digging I've found that it is caused by expression (= ::expired v) in clojure.core.cache.wrapped/lookup-or-miss.

What happens is that = internally calls clojure.lang.Util/equiv (since LazyMap implements IPersistentCollection) and then, after some dispatching, equiv is called to check whether the contents of a lazy map equals to other object (implicitly other map). This is the desired behavior and lazy map realizes all values to make comparison possible.

However, when comparing a map-like object to something which is not a map (nor a collection), short-circuit would be welcome as soon as we know that it will for sure return false. But changing that is probably more related to Clojure itself and things like CLJ-1375.

What could be done on core.cache's side, if that's not too problematic, would be a replacement of

(= ::expired v) with (identical? ::expired v)

in clojure.core.cache.wrapped.

It would not only fix corner cases like mine but also speed things up a bit (explicit referential equality rocks when it comes to Clojure keywords).

Other expressions where that could be changed (just in case) are:
(= ::nope ret) and (= ::nil v) from clojure.core.cache.

Answer selected: Is it legal for a namespace to start with a number?

Mon, 23 Feb 2026 19:13:52 +0000

As far as I can tell, there is no reason a namespace segment other than the first can't start with a number.

Closed: from-java does not convert Boolean to clojure keyword

Mon, 23 Feb 2026 16:47:20 +0000

Given a class:

public class BoolTest {
    private Boolean aBoolean;
    private String aString;

    public Boolean isABoolean() {
        return aBoolean;
    }

    public void setABoolean(Boolean value) {
        this.aBoolean = value;
    }

    public String getAString() {
        return aString;
    }

    public void setAString(String aString) {
        this.aString = aString;
    }
}

Test:

(def example (BoolTest.))

(defn run-test []
  (do
    (-> example
      (.setABoolean true))
    (-> example
      (.setAString "something"))
    (from-java example)))

***** Actual:
(test/run-test) => {:AString "something"}

**** Expected:
(test/run-test) => {:AString "something" :ABoolean true}

Closed: java.util.Date should not be converted

Mon, 23 Feb 2026 16:46:47 +0000

(from-java (java.util.Date.)) returns

{:day 2, :date 22, :time 1548156165905, :month 0, :seconds 45, :year 119, :timezoneOffset 0, :hours 11, :minutes 22}

but it makes more sense not to convert date objects as they are effectively primitives within Clojure. Can submit PR for this if approved.

Closed: incorrect org.clojure/java.data convert java.util.Date use getter and setter

Mon, 23 Feb 2026 16:46:17 +0000

in package org.clojure/java.data

(cjd/from-java (java.util.Date.)) will use setter and getter method of java.util.Date, which produce incorrect clojure object,

because java.util.Date is a basic class of java language, it's better keep "::do-not-convert".

so i add this class to ::do-not-convert classify.

Closed: Translate - into camel casing in to-java

Mon, 23 Feb 2026 16:44:54 +0000

Currently, if a class has a setter like {{setMyThing}}, the hash must contain {{:myThing}} for {{to-java}} to call it.

It would be great is {{:my-thing}} could be used instead as it would look less Java-ish.

Closed: Pass JDBC connection properties when creating connection via connection-uri

Mon, 23 Feb 2026 16:44:25 +0000

Hi there

In java.jdbc, when using a raw connection uri, properties cannot be passed in and have to be part of the uri, except for username and password which can be taken from the db-spec, as there is a DriverManager constructor that takes username and password specifically. DriverManager does, however, provide another constructor in which any properties can be provided, including username and password. Would it be possible to use that constructor instead? Here is what the change would look like: https://github.com/dmcgillen/java.jdbc/commit/95edd36997320d8dc6882ea371d88c901e49f465#diff-3a9a3475f16407a50d922fad53957b01L293.

For context, this has come up for me since I've been using an AWS Secrets Manager JDBC wrapper, which takes the secret id as a connection uri. I'd still like to provide other JDBC properties, but they are expected to be provided as in the change above, and it seems like a good idea to support properties being passed in this way.

Let me know if I should have created a JIRA rather than posting here and I can do so (if this change is a good idea, of course).

Thanks

Closed: Make it easier to test java.jdbc in other environments

Mon, 23 Feb 2026 16:43:32 +0000

Make the versions properties in {{pom.xml}} and/or {{project.clj}}, make the database names, usernames, and passwords configurable via environment variables.

This came up via a suggestion from the PostgreSQL community -- see this pull request for guidance on what we could open up: https://github.com/clojure/java.jdbc/pull/44/files

Closed: to-java not working when setter takes Map as parameter

Mon, 23 Feb 2026 15:28:05 +0000

If I have the following class:

`
public class ClojureTestBean {

private java.util.Map foo;

public void setFoo(Map foo) {
    this.foo = foo;
}

public Map getFoo() {
    return foo;
}

}
`

And I run the following clojure:

`
(def bean-instance (ClojureTestBean.))
(. bean-instance setFoo {"bar" "baz"})

(def bean-instance-as-map (from-java bean-instance))

(def new-bean-instance (to-java ClojureTestBean bean-instance-as-map))
`

The final line throws a {{java.lang.InstantiationException: java.util.Map}} exception (full stack trace found below). It looks like there's a {{to-java}} method that, when it gets a {{APersistentMap}}, tries to create an instance of the type of the parameter which in this case is a {{Map}} interface, which of course cannot be instantiated.

I'm wondering why the {{APersistentMap}} wouldn't be passed in directly, as it implements the {{Map}} interface?

`
CompilerException java.lang.InstantiationException: java.util.Map, compiling:(scratchpad.clj:13:24)
java.lang.InstantiationException: java.util.Map, compiling:(scratchpad.clj:13:24)

at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3628)
at clojure.lang.Compiler$DefExpr.eval(Compiler.java:439)
at clojure.lang.Compiler.eval(Compiler.java:6787)
at clojure.lang.Compiler.load(Compiler.java:7227)
at user$eval1676.invoke(form-init2280240325964091253.clj:1)
at clojure.lang.Compiler.eval(Compiler.java:6782)
at clojure.lang.Compiler.eval(Compiler.java:6745)
at clojure.core$eval.invoke(core.clj:3081)
at clojure.main$repl$read_eval_print__7099$fn__7102.invoke(main.clj:240)
at clojure.main$repl$read_eval_print__7099.invoke(main.clj:240)
at clojure.main$repl$fn__7108.invoke(main.clj:258)
at clojure.main$repl.doInvoke(main.clj:258)
at clojure.lang.RestFn.invoke(RestFn.java:1523)
at clojure.tools.nrepl.middleware.interruptible_eval$evaluate$fn__609.invoke(interruptible_eval.clj:53)
at clojure.lang.AFn.applyToHelper(AFn.java:152)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invoke(core.clj:630)
at clojure.core$with_bindings_STAR_.doInvoke(core.clj:1868)
at clojure.lang.RestFn.invoke(RestFn.java:425)
at clojure.tools.nrepl.middleware.interruptible_eval$evaluate.invoke(interruptible_eval.clj:51)
at clojure.tools.nrepl.middleware.interruptible_eval$interruptible_eval$fn__651$fn__654.invoke(interruptible_eval.clj:183)
at clojure.tools.nrepl.middleware.interruptible_eval$run_next$fn__644.invoke(interruptible_eval.clj:152)
at clojure.lang.AFn.run(AFn.java:22)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:744)

Caused by: java.lang.InstantiationException: java.util.Map

at java.lang.Class.newInstance(Class.java:359)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at clojure.lang.Reflector.invokeMatchingMethod(Reflector.java:93)
at clojure.lang.Reflector.invokeNoArgInstanceMember(Reflector.java:313)
at clojure.java.data$fn__247.invoke(data.clj:95)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.java.data$make_setter_fn$fn__232.invoke(data.clj:55)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invoke(core.clj:630)
at clojure.java.data$fn__247.invoke(data.clj:101)
at clojure.lang.MultiFn.invoke(MultiFn.java:233)
at clojure.lang.AFn.applyToHelper(AFn.java:156)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.lang.Compiler$InvokeExpr.eval(Compiler.java:3623)

Closed: Handle primitive types and arrays

Mon, 23 Feb 2026 15:26:36 +0000

Right now, there is no special handling for methods with primitive or array parameters.
This results in errors, when trying to use bean classes, that have such methods, with to-java and from-java.

The attached patch implements handling of primitives and arrays in the following manner:
- When the :default methods of from-java and to-java see an array type, they extend the multimethods for that array type.
Issue: Is Iterable the right interface to extend the multimethod to? Sequential also came to mind, but Iterable was used elsewhere.

Values that hit a numeric primitive slot (in to-java) are manually boxed, so they aren't passed as longs.

Closed: to-java not working on some setters

Mon, 23 Feb 2026 15:25:47 +0000

In this example the last test fails.

I have used org.codehause.mojo.rpm.Mapping(link: 1) as the example as this is where I discovered the bug.

(link: 1) http://mojo.codehaus.org/rpm-maven-plugin/apidocs/org/codehaus/mojo/rpm/Mapping.html

Tests:

(do
(use 'clojure.java.data

       'clojure.test)

(import '(link: org.codehaus.mojo.rpm Mapping))

(testing "setting normally"

(let (link: mapping (Mapping.))

	(.setConfiguration mapping "a value")
	(.setDirectory mapping "/tmp")

	(is (= (.getDirectory mapping) "/tmp"))
	(is (= (.getConfiguration mapping) "a value"))))

(testing "setting via java-data"

(let (link: mapping (to-java Mapping {:configuration "a value" :directory "/tmp"}))
  (is (= (.getDirectory mapping) "/tmp"))
  (is (= (.getConfiguration mapping) "a value")))))

Closed: from-java on an object with Boolean attribute = false returns "bad" Booleans

Mon, 23 Feb 2026 15:25:09 +0000

Calling from-java on an object that as a Boolean attribute that is false can return boxed Booleans that are not Boolean/FALSE.
This results in a boolean that is equal to false, but results in the true path of if.

`
(def bool (:absolute (from-java (URI. ""))))

bool
=> false
(= bool false)
=> true
(if bool true false)
=> false
`

This leads to really confusing behavior.
As clojure won't change the behavior of if (https://dev.clojure.org/jira/browse/CLJ-1718) and we don't control the construction of the boolean, I think from-java should be aware of this problem and fix it.

This could be fixed by adding an extra method for Boolean that reconstructs the Boolean in the right way, though I'm not sure what the best way would look like.

Feature Request:Make anonymous fn/reify class name IDs per namespace instead of one global counter

Wed, 18 Feb 2026 15:34:38 +0000

Compiled anonymous functions and reify classes get names like ns$fn__4532, where the numeric suffix comes from a global AtomicInteger counter
(RT.nextID()).

This counter is shared across the entire runtime and is consumed by fn classes, reify classes, constants tables, gensyms, etc.

The problem is that because the counter is global, any code change shifts the IDs for everything compiled after it. This makes profiling across builds
really painful, you can't meaningfully compare flame graphs because all the class names change even in code you didn't touch.

I'd like to propose scoping the ID counter per-namespace instead. Since the namespace is already part of the class name prefix, uniqueness is still
guaranteed. This would eliminate the cascading effect across unchanged namespaces and make profiling diffs actually useful.

I'm not sure what's the downsides of this, but from what I saw of AtomicInteger, it isn't used a lot to break things.

Thank you!

Answered: Is it valid for metadata to have metadata?

Tue, 17 Feb 2026 15:10:58 +0000

Thanks for the additional info! I do think this is bug, which I've filed at https://clojure.atlassian.net/browse/CLJ-2941 and patch is welcome.

If you need to sign the contributor agreement or get access to jira, please follow process at https://clojure.org/dev/dev#_becoming_a_contributor

Answered: clojure.java.doc.api/javadoc-data-fn does not include constructor info

Fri, 13 Feb 2026 18:33:40 +0000

That functionality is now present in the v0.1.4 release.

Answered: javadoc-data-fn does not find selected method for inherited methods

Fri, 13 Feb 2026 18:33:01 +0000

Great feedback.

We were indeed not looking for inherited methods. That functionality is now present in the v0.1.4 release.

Answered: does deps.edd support "exclusion" with wild cards ?

Sun, 08 Feb 2026 17:14:18 +0000

There is an existing enhancement jira for this at https://clojure.atlassian.net/browse/TDEPS-141