Clojure Q&A - Recent questions tagged bug

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

Mon, 11 May 2026 12:59:06 +0000

We're seeing what looks like a violation of the keyword-interning invariant in production. The bug is deterministic (repeats thousands of times in the same order on the same Aleph/Netty thread) and is cleared by recompiling the affected namespaces via nREPL.

(when (and (map? result) (nil? (:payload result)))   ; this WHEN fires
  (let [payload-key (->> (keys result)
                         (filter #(.contains (pr-str %) "payload"))
                         first)
        payload-via-key (when payload-key (get result payload-key))]
    (log/warn {:result-type                   (str (type result))
               :result-keys                   (pr-str (keys result))
               :payload-key-equals-literal?   (= payload-key :payload)
               :payload-key-identical?        (identical? payload-key :payload)
               :payload-via-found-key-nil?    (nil? payload-via-key)}
              "diagnostic")))

Logged values when the bug fires:

{:result-type                   clojure.lang.PersistentArrayMap
 :result-keys                   (:payload :aws-xray)
 :payload-key-equals-literal?   true
 :payload-key-identical?        true
 :payload-via-found-key-nil?    false}

So:

The (:payload result) in the when returned nil.
A few lines later, the diagnostic body proves that the first key in (keys result) IS the body-site :payload literal by identity (and therefore by =, since Keyword inherits Object.equals).
(get result that-key) returns the actual non-nil payload value.

PersistentArrayMap.indexOf uses == for Keyword keys, so the only way (:payload result) returns nil while (keys result) yields a key that is identical? to :payload at a nearby site is if the :payload literal at the WHEN site and the :payload literal at the body site are two different Keyword instances, even though they're written identically in one source-level function.

We compareed the :payload literal with the payload-key and found that both have -

identical content hashcode (-383036092)
identical name bytes [0x70 0x61 0x79 0x6C 0x6F 0x61 0x64]
identical codepoints
same classloader

so it really looks like two distinct interned Keyword instances with the same name.

Environment

Clojure 1.12.4
Eclipse Temurin JDK 25, Shenandoah GC, virtual threads enabled
ARM64 (AWS Graviton, ECS Fargate)
Aleph + Netty, transit-clj/transit-java for decoding

Questions

Could this be a bug in JVM / Clojure runtime?
Has similar behavior been seen in other cases?
What more evidence could we capture?

`derive [tag] [parent]` accepts non namespaced keyword/symbol as `tag` ?

Wed, 19 Nov 2025 21:23:15 +0000

Hello

derive's doc says:

Establishes a parent/child relationship between parent and
tag. Parent must be a namespace-qualified symbol or keyword and
child can be either a namespace-qualified symbol or keyword or a
class.

But in practice, ClojureScript accepts non-namespaced tag:

(derive :a ::b)
; nil
(isa? :a ::b)
; true

Clojure throws.

Is ClojureScript behavior expected or a bug?

Same question for the derive [h tag parent] form, which seems to accept non-namespaced keyword/symbol for both tag and parent, this time on both Clojure and ClojureScript:

(derive (make-hierarchy) :a :b)
; {:parents {:a #{:b}}, :ancestors {:a #{:b}}, :descendants {:b #{:a}}}

Cannot compile namespace including `+` in clojurescript

Tue, 20 May 2025 10:12:48 +0000

Trying to compile any namespace including + fails in clojurescript

e.g.:

(ns test+.core)

(println "Hello, World!")

compiled with clojurescript "1.12.42"

clj -M --main cljs.main --compile test+.core

results in

 `Namespace test+.core does not exist.`

Trying to include the namespace from another gives:

Unexpected error (ExceptionInfo) compiling at (REPL:1).
No such namespace: test+.core, could not locate test_PLUS_/core.cljs, test_PLUS_/core.cljc, or JavaScript source providing "test+.core" (Please check that namespaces with dashes use underscores in the ClojureScript file name) in file /home/sigvesn/clojure/cljs-test/src/other.cljs

Note that it is possible to compile the namespace from regular clojure.

This is relevant because the clojure walk library uses + in the namespace

Repo with code to reproduce

Comparing ratios with BigDecimals can throw

Fri, 21 Feb 2025 20:52:49 +0000

Observe:

(< 1/4 0.5M)
;=> true        ; as expected

(< 1/3 0.5M)
; Execution error (ArithmeticException) at java.math.BigDecimal/divide (BigDecimal.java:1783).
; Non-terminating decimal expansion; no exact representable decimal result.

This is because Clojure tries to coerce the ratio to a BigDecimal, which can fail.

This worked (and produced expected results) in Clojure up to 1.2.1; the current behaviour is from 1.3.0 onwards. Not sure whether this is a bug or expected behaviour; in either case, I haven’t seen it documented.

>, <=, >= all exhibit the same behaviour. = works.

I’ve also noticed that = can’t determine whether a ratio is equal to a bigdec, although < and > do sometimes produce a good answer:

((juxt < = >) 1/2 0.5M)
;=> [false false false]

((juxt < = >) 1/4 0.5M)
;=> [true false false]

The same is true of ratios and doubles:

((juxt < = >) 1/2 0.5M)
;=> [false false false]

((juxt < = >) 1/4 0.5M)
;=> [true false false]

This seems contrary to the docstring of =, which states that „[it] compares numbers and collections in a type-independent manner”.

clojure.pprint/pprint bug when using the code-dispatch table

Fri, 10 Nov 2023 14:06:05 +0000

There seams to be a bug in clojure.pprint/pprint when using the code-dispatch table and printing let. It happens on Clojure and ClojureScript.

Clojure 1.11.1
user=> (require '[clojure.pprint :as pp])

user=> 
(binding [pp/*print-pprint-dispatch* pp/code-dispatch]
  (pp/pprint
   '(let)))

((let)) ;; prints some extra parenthesis

(binding [pp/*print-pprint-dispatch* pp/code-dispatch]
  (pp/pprint
   '(let*)))

(let*) ;; doesn't happen when pprinting any other form

Clojurescript issue in 1.11.121 and master when compiling

Tue, 12 Sep 2023 22:01:58 +0000

When compiling a file with :

clj -Sdeps '{:paths ["src"] :deps {org.clojure/clojurescript {:mvn/version "1.11.121"}}}' -M -m cljs.main -co '{:main org.foo.myscript}' --compile

the compilation will work fine, but if after that you run cljs.main --repl the browser repl will start, but evaluating forms on it will not work since evaluation will never finish.

This exact same commands work fine in 1.11.60.

After some debugging the issue seems to be caused by the current compiler never adding

document.write('<script>goog.require("clojure.browser.repl.preload");</script>');

to the resulting js file.

This is caused by :

https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/closure.clj#L2500-L2501

not adding the preload because :browser-repl isn't true.

The breaking change comes from this line:

https://github.com/clojure/clojurescript/blob/master/src/main/clojure/cljs/cli.clj#L498

which removes :browser-repl from the options because we are just compiling and there is no repl involved.

Looks like the behavior was explicitly changed by this commit :

https://github.com/clojure/clojurescript/commit/9c01d9b0a70ada1cb17cf3ce65ae93d76d0d3b08

Reverting the commit fixes the issue.

Why doesn't `type` in CLJS check `:type` on its arguments meta like CLJ does?

Sun, 23 Jul 2023 14:56:02 +0000

In CLJ a check for :type on the meta happens and then falls back to returning the constructor class. In CLJS only the constructor class is returned. It would be nice to have these consistent for usage with multimethods etc.

Locals clearing issue with a type-hinted vs non-type-hinted letfn?

Fri, 16 Jun 2023 16:19:58 +0000

Hey folks - I seem to be getting a locals clearing issue with a type-hinted vs non-type-hinted letfn:

(defn- letfn-prim []
  (letfn [(f [coll ^long n]
            )]
    (f (take 3 (range)) 0)))

(defn- letfn-noprim []
  (letfn [(f [coll n]
            )]
    (f (take 3 (range)) 0)))

(in practice, I'm lazily processing coll within f and wanted to avoid retaining the head)

The noprim variant clears the coll param correctly; the prim version doesn't seem to.

(I'm aware letfn doesn't fully support type-hints, but this one seems to be more than just an unexpected boxing, and affects more than just the hinted variable)

In both cases, the caller is calling f.invoke(Object) (invokeinterface clojure/lang/IFn.invoke:(Ljava/lang/Object;Ljava/lang/Object;)Ljava/lang/Object;), but the difference comes in the f function. (Arguably the hinted version could call invokePrim directly, but as I say, aware letfn doesn't fully support type-hints)

In the unhinted case, invoke is trivial:

  public java.lang.Object invoke(java.lang.Object, java.lang.Object);
    Code:
       0: aconst_null
       1: areturn

(adding more of a body clears the param as soon as it can)

but in the hinted case, we get this:

  public final java.lang.Object invokePrim(java.lang.Object, long);
    Code:
       0: aconst_null
       1: areturn

  public java.lang.Object invoke(java.lang.Object, java.lang.Object);
    Code:
       0: aload_0
       1: aload_1
       2: aload_2
       3: checkcast     #22                 // class java/lang/Number
       6: invokestatic  #28                 // Method clojure/lang/RT.longCast:(Ljava/lang/Object;)J
       9: invokeinterface #30,  4           // InterfaceMethod clojure/lang/IFn$OLO.invokePrim:(Ljava/lang/Object;J)Ljava/lang/Object;
      14: areturn

The invoke calls through to invokePrim as normal, but it doesn't clear its locals before doing so. compare to

(defn- defn-prim [coll ^long n]
  )

whose bytecode does clear the object in its invoke method:

  public static java.lang.Object invokeStatic(java.lang.Object, long);
    Code:
       0: aconst_null
       1: areturn

  public java.lang.Object invoke(java.lang.Object, java.lang.Object);
    Code:
       0: aload_1
       1: aconst_null
       2: astore_1      // <--- local cleared here
       3: aload_2
       4: checkcast     #21                 // class java/lang/Number
       7: invokestatic  #27                 // Method clojure/lang/RT.longCast:(Ljava/lang/Object;)J
      10: invokestatic  #29                 // Method invokeStatic:(Ljava/lang/Object;J)Ljava/lang/Object;
      13: areturn

  public final java.lang.Object invokePrim(java.lang.Object, long);
    Code:
       0: aload_1
       1: aconst_null
       2: astore_1
       3: lload_2
       4: invokestatic  #29                 // Method invokeStatic:(Ljava/lang/Object;J)Ljava/lang/Object;
       7: areturn

Cheers!

James

Why does this work in CLJS but doesn't in JVM Clojure?

Thu, 27 Apr 2023 19:12:03 +0000

This looks like a bug in ClojureScript 1.11.54 :

(conj {} [:a 1] '([:b 2] [:c 3]) '([:d 4]))

In Clojure on the JVM this is an error:

cljs.user> (conj {} [:a 1] '([:b 2] [:c 3]) '([:d 4]))
{:a 1, :b 2, :c 3, :d 4}
cljs.user> :cljs/quit
nil
user> (conj {} [:a 1] '([:b 2] [:c 3]) '([:d 4]))
Execution error (ClassCastException) at user/eval17754 (REPL:25).
class clojure.lang.PersistentVector cannot be cast to class java.util.Map$Entry (clojure.lang.PersistentVector is in unnamed module of loader 'app'; java.util.Map$Entry is in module java.base of loader 'bootstrap')

let binding does not infer primitive type of type hinted global var

Mon, 30 Jan 2023 03:23:21 +0000

When you type hint a var such as:

(def ^{:tag 'long} k 100)

And refer to it in a let binding:

(let [i k]
  (+ i 10))

The binding is unable to properly infer that it is a primitive type as it was hinted:

(set! *unchecked-math* :warn-on-boxed)
(def ^{:tag 'long} k 100)
(let [i k]
  (+ i 10))
;;=> Boxed math warning, unchecked_add(java.lang.Object,long).

It looks like it might be caused by a bug in the Compiler where for some reason, the expression of the var k is marked as not having a java class, even though it has one:

(defmacro inspect-local []
  (println
   (into {}
         (map (fn[[k v]]
                [k {:tag (.-tag v)
                    :class (.getJavaClass v)
                    :primitive? (.isPrimitive (.getJavaClass v))
                    :has-java-class? (.hasJavaClass v)}]))
         &env)))

(let [i k]
  (inspect-local)
  (+ i 10))

;;=> {i {:tag nil, :class long, :primitive? true, :has-java-class? false}}

As we can see, .hasJavaClass returns false, but .getJavaClass returns the Long/TYPE class.

I suspect that the compiler checks for .hasJavaClass before calling .getJavaClass, and since .hasJavaClass is erroneously false here, it would cause the compiler to think it isn't, and that the type can't be inferred.

I'm not too sure where in the Compiler this is, but I found the following: https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Compiler.java#L1341

Where we see the compiler is first checking for .hasJavaClass:

 if(e instanceof MaybePrimitiveExpr && e.hasJavaClass() && ((MaybePrimitiveExpr)e).canEmitPrimitive())

`(s/merge X Y)` disables conformation for `:*-un` keys in X

Sat, 21 Jan 2023 22:21:34 +0000

When merging map specs with unqualified keys, only the last spec retains its conformation behavior:

(s/def ::int-or-string (s/or :int int? :str string?))
(s/def ::a ::int-or-string)
(s/def ::b ::int-or-string)
(s/def ::a-un (s/keys :opt-un [::a]))
(s/def ::b-un (s/keys :opt-un [::b]))
(s/def ::merge-un (s/merge ::a-un ::b-un))
(s/conform ::merge-un {:a 100 :b "foo"})
;;=> {:a 100, :b [:str "foo"]}

Compare the behavior with qualified keys:

(s/def ::a-qual (s/keys :opt [::a]))
(s/def ::b-qual (s/keys :opt [::b]))
(s/def ::merge-qual (s/merge ::a-qual ::b-qual))
(s/conform ::merge-qual {::a 100 ::b "foo"})
;;=> #:user{:a [:int 100], :b [:str "foo"]}

CLI on Powershell cannot read piped input

Tue, 10 Jan 2023 01:13:51 +0000

On Powershell, when you run the command

Write-Output 'foo' | clojure -M -e '(println (slurp *in*))'

the process hangs and waits for interactive input, rather than printing the piped input.

This seems to be because the calls to java in the Powershell implementation of clj/clojure do not explicitly hand over $Input when it is bound.

Based on this discussion on a similar issue, this proof of concept demonstrates a potential fix:

PS> Get-Content clj.ps1
if ($MyInvocation.ExpectingInput) {
        $Input | java -classpath "$(clojure -Spath)" clojure.main -e '(println (slurp *in*))'
} else {
        java -classpath "$(clojure -Spath)" clojure.main -e '(println (slurp *in*))'
}
PS> Write-Output 'foo' | .\clj.ps1
foo

PS> .\clj.ps1
This text was supplied interactively, followed by a ^C
This text was supplied interactively, followed by a ^C

PS>

h/t @hiredman on the Clojurians Slack for finding that GitHub discussion

Pesky loop bug resulting in 0xFFFFFFFF with BufferedReader (java interop)

Sun, 26 Dec 2021 13:20:55 +0000

Hello --

I'm learning Clojure and its Java interop stuff. I am trying to emulate this function:

 public String readAllCharsOneByOne(BufferedReader bufferedReader) throws IOException {
    StringBuilder content = new StringBuilder();
       
    int value;
    while ((value = bufferedReader.read()) != -1) {
        content.append((char) value);
    }
       
    return content.toString();
}

So far, I've been able to reason that the parts I need are:

(def myfile "/path/to/svenska_sample.txt")
(import java.io.BufferedReader)
(import java.io.FileReader)
(import java.lang.StringBuilder)
(import java.lang.Character)
 
(def a-FileReader (FileReader. myfile))
(def bufferedReader (BufferedReader. a-FileReader))
(def content (StringBuilder.))

which works

user> (.append content (Character/toChars (.read bufferedReader)))
#object[java.lang.StringBuilder 0x490447d0 "\nDe"]
user> (.append content (Character/toChars (.read bufferedReader)))
#object[java.lang.StringBuilder 0x490447d0 "\nDen"]
user> (.append content (Character/toChars (.read bufferedReader)))
#object[java.lang.StringBuilder 0x490447d0 "\nDen "]
user> (.append content (Character/toChars (.read bufferedReader)))
#object[java.lang.StringBuilder 0x490447d0 "\nDen t"]
user> (.append content (Character/toChars (.read bufferedReader)))
#object[java.lang.StringBuilder 0x490447d0 "\nDen ty"]
user> (.append content (Character/toChars (.read bufferedReader)))
#object[java.lang.StringBuilder 0x490447d0 "\nDen typ"]
user> (.append content (Character/toChars (.read bufferedReader)))
#object[java.lang.StringBuilder 0x490447d0 "\nDen typi"]

The file is a small text file UTF-8 encoded in Linux with the following content:

❯ cat svenska_sample.txt

Den typiska impulsiva olycksfågeln är en ung man som kraschar flera bilar, och ofta skryter lite med det, i varje fall när han är tillsammans med sina vänner._. För dem har otur i det närmaste blivit en livsstil, och de råkar konstant ut för olyckor, stora som små. Olycksfåglar kallar vi dem. Hur många det finns kan ingen med säkerhet säga, för det finns inga konkreta definitioner på denna grupp, och heller ingen given avgränsning av den. Att de finns, råder det emellertid ingen tvekan om, varken på sjukhusens akutmottagningar eller i försäkringsbranschen

I wrote a function, with my brand new Clojure Java interop chops, that looks like this:

;; COMPILES  - BUT CAN'T GET AROUND THE 0XFFFFFFF BUG
(defn pt%% [file]
   (let [afr (FileReader. file); instances of FileReader, BufferedReader, StringBuffer
         bfr (BufferedReader. afr)
         ct (StringBuilder.)
         val (.read bfr)
         this-list (list afr bfr ct)]
         ; (apply println this-list)
         (loop []
               (when (not (= val -1))
                 (.append ct (Character/toChars (.read bfr))))
               (recur))
                ; when finished...
         (.toString ct)))

but it borks with the following error:

user> (pt%% myfile)
Execution error (IllegalArgumentException) at java.lang.Character/toChars (Character.java:8572).
Not a valid Unicode code point: 0xFFFFFFFF

What in the world could be causing this (NOTE: I am not a Java programmer)?
Here is the hex dump of the file text file:

❯ cat svenska_sample.hexdump

00000000: 0a44 656e 2074 7970 6973 6b61 2069 6d70  .Den typiska imp
00000010: 756c 7369 7661 206f 6c79 636b 7366 c3a5  ulsiva olycksf..
00000020: 6765 6c6e 20c3 a472 2065 6e20 756e 6720  geln ..r en ung
00000030: 6d61 6e20 736f 6d20 6b72 6173 6368 6172  man som kraschar
00000040: 2066 6c65 7261 2062 696c 6172 2c20 6f63   flera bilar, oc
00000050: 6820 6f66 7461 2073 6b72 7974 6572 206c  h ofta skryter l
00000060: 6974 6520 6d65 6420 6465 742c 2069 2076  ite med det, i v
00000070: 6172 6a65 2066 616c 6c20 6ec3 a472 2068  arje fall n..r h
00000080: 616e 20c3 a472 2074 696c 6c73 616d 6d61  an ..r tillsamma
00000090: 6e73 206d 6564 2073 696e 6120 76c3 a46e  ns med sina v..n
000000a0: 6e65 722e 5f2e 2046 c3b6 7220 6465 6d20  ner._. F..r dem
000000b0: 6861 7220 6f74 7572 2069 2064 6574 206e  har otur i det n
000000c0: c3a4 726d 6173 7465 2062 6c69 7669 7420  ..rmaste blivit
000000d0: 656e 206c 6976 7373 7469 6c2c 206f 6368  en livsstil, och
000000e0: 2064 6520 72c3 a56b 6172 206b 6f6e 7374   de r..kar konst
000000f0: 616e 7420 7574 2066 c3b6 7220 6f6c 7963  ant ut f..r olyc
00000100: 6b6f 722c 2073 746f 7261 2073 6f6d 2073  kor, stora som s
00000110: 6dc3 a52e 204f 6c79 636b 7366 c3a5 676c  m... Olycksf..gl
00000120: 6172 206b 616c 6c61 7220 7669 2064 656d  ar kallar vi dem
00000130: 2e20 4875 7220 6dc3 a56e 6761 2064 6574  . Hur m..nga det
00000140: 2066 696e 6e73 206b 616e 2069 6e67 656e   finns kan ingen
00000150: 206d 6564 2073 c3a4 6b65 7268 6574 2073   med s..kerhet s
00000160: c3a4 6761 2c20 66c3 b672 2064 6574 2066  ..ga, f..r det f
00000170: 696e 6e73 2069 6e67 6120 6b6f 6e6b 7265  inns inga konkre
00000180: 7461 2064 6566 696e 6974 696f 6e65 7220  ta definitioner
00000190: 70c3 a520 6465 6e6e 6120 6772 7570 702c  p.. denna grupp,
000001a0: 206f 6368 2068 656c 6c65 7220 696e 6765   och heller inge
000001b0: 6e20 6769 7665 6e20 6176 6772 c3a4 6e73  n given avgr..ns
000001c0: 6e69 6e67 2061 7620 6465 6e2e 2041 7474  ning av den. Att
000001d0: 2064 6520 6669 6e6e 732c 2072 c3a5 6465   de finns, r..de
000001e0: 7220 6465 7420 656d 656c 6c65 7274 6964  r det emellertid
000001f0: 2069 6e67 656e 2074 7665 6b61 6e20 6f6d   ingen tvekan om
00000200: 2c20 7661 726b 656e 2070 c3a5 2073 6a75  , varken p.. sju
00000210: 6b68 7573 656e 7320 616b 7574 6d6f 7474  khusens akutmott
00000220: 6167 6e69 6e67 6172 2065 6c6c 6572 2069  agningar eller i
00000230: 2066 c3b6 7273 c3a4 6b72 696e 6773 6272   f..rs..kringsbr
00000240: 616e 7363 6865 6e0a                      anschen.

I then changed the code (see below), because of some suggestions that the problem might be my use of recur.

And now it complains that a previous form that was working '(.append etc..') doesn't and the same error remains.

user> (pt5 myfile)

Execution error (IllegalArgumentException) at java.lang.Character/toChars (Character.java:8572).
Not a valid Unicode code point: 0xFFFFFFFF

(defn pt5 [file]

   (let [afr (FileReader. file); instances of FileReader, BufferedReader, StringBuffer
         bfr (BufferedReader. afr)
         ct (StringBuilder.)
         this-list (list afr bfr ct)]
         ; (apply println this-list)
         (loop [val (.read bfr)]
               (when (not (= val -1))
                 (.append ct (Character/toChars (.read bfr))))
               (recur val))
                ; when finished...
                (.toString ct)))

Harder then it seemed at first sight...
Any help is greatly appreciated.`
-- Hank

Bug in ClojureScript type inference?

Tue, 07 Dec 2021 00:21:00 +0000

Further to a recent conversation in the ClojureScript topic in Slack, Dan Sutton suggested that I create an issue here.

I think I may have found a bug in ClojureScript's type inference. I've created a minimal reproduction here:

https://github.com/paulbutcher/clojurescript-type-inference-bug

The following code generates a warning:

  cljs.core/-, all arguments must be numbers, got [#{js/clj-nil clj-nil} #{js/clj-nil clj-nil}] instead
  (- (ocall js/Math :random) (ocall js/Math :random))
  ^---

I would expect that I could fix it like this:

(- ^js/number (ocall js/Math :random) ^js/number (ocall js/Math :random))

But that gives me exactly the same error.

tools.build uber's default conflict handlers don't append to META-INF/services properly

Fri, 26 Nov 2021 17:29:12 +0000

Our project has some dependencies that register parsers for various file formats via the java services framework.

We’re using b/uber and are finding some META-INF/services/ definitions are not correctly being appended.

I’ve chased this down to the regex in the default-handlers being ^META-INF/services/ instead of something more like ^META-INF/services/.*

The current regex would match under re-find, but not under re-matches which the implementation uses.

tools.build uber task fails when the dependency tree contains a dep which has no jar

Tue, 12 Oct 2021 14:00:42 +0000

The clojure.tools.build.api/uber task fails when the dependency tree contains a dep which has no jar.

A relatively minimal failing test case is the following tools.build task:

(ns build 
  (:require [clojure.tools.build.api :as b]))

(defn failing-uber [_]
    (b/uber {:class-dir "classes"
     :uber-file "foo.jar"
     :basis (b/create-basis {:project {:deps {'org.apache.jena/apache-jena-libs {:mvn/version "4.2.0" :extension "pom"} }}})})

(comment 
   (failing-uber {})
 )

Evaluating the above function results in the following exception:

1. Unhandled clojure.lang.ExceptionInfo
   Unexpected lib file:
   /Users/rick/.m2/repository/org/apache/jena/apache-jena-libs/4.2.0/apache-jena-libs-4.2.0.pom
   {}
                  uber.clj:  182  clojure.tools.build.tasks.uber/explode
                  uber.clj:  141  clojure.tools.build.tasks.uber/explode
                  uber.clj:  257  clojure.tools.build.tasks.uber/uber/fn/fn
     PersistentVector.java:  343  clojure.lang.PersistentVector/reduce
                  core.clj: 6829  clojure.core/reduce
                  core.clj: 6812  clojure.core/reduce
                  uber.clj:  256  clojure.tools.build.tasks.uber/uber/fn
             protocols.clj:   49  clojure.core.protocols/iter-reduce
             protocols.clj:   75  clojure.core.protocols/fn
             protocols.clj:   75  clojure.core.protocols/fn
             protocols.clj:   13  clojure.core.protocols/fn/G
                  core.clj: 6830  clojure.core/reduce
                  core.clj: 6812  clojure.core/reduce
                  uber.clj:  254  clojure.tools.build.tasks.uber/uber
                  uber.clj:  241  clojure.tools.build.tasks.uber/uber
                  Var.java:  384  clojure.lang.Var/invoke
                   api.clj:  394  clojure.tools.build.api/uber
                   api.clj:  339  clojure.tools.build.api/uber
                      REPL:   21  build/eval25043
                      REPL:   21  build/eval25043
             Compiler.java: 7181  clojure.lang.Compiler/eval
             Compiler.java: 7136  clojure.lang.Compiler/eval
                  core.clj: 3202  clojure.core/eval
                  core.clj: 3198  clojure.core/eval
    interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn/fn
                  AFn.java:  152  clojure.lang.AFn/applyToHelper
                  AFn.java:  144  clojure.lang.AFn/applyTo
                  core.clj:  667  clojure.core/apply
                  core.clj: 1977  clojure.core/with-bindings*
                  core.clj: 1977  clojure.core/with-bindings*
               RestFn.java:  425  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   87  nrepl.middleware.interruptible-eval/evaluate/fn
                  main.clj:  437  clojure.main/repl/read-eval-print/fn
                  main.clj:  437  clojure.main/repl/read-eval-print
                  main.clj:  458  clojure.main/repl/fn
                  main.clj:  458  clojure.main/repl
                  main.clj:  368  clojure.main/repl
               RestFn.java:  137  clojure.lang.RestFn/applyTo
                  core.clj:  667  clojure.core/apply
                  core.clj:  662  clojure.core/apply
                regrow.clj:   20  refactor-nrepl.ns.slam.hound.regrow/wrap-clojure-repl/fn
               RestFn.java: 1523  clojure.lang.RestFn/invoke
    interruptible_eval.clj:   84  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:   56  nrepl.middleware.interruptible-eval/evaluate
    interruptible_eval.clj:  152  nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
                  AFn.java:   22  clojure.lang.AFn/run
               session.clj:  202  nrepl.middleware.session/session-exec/main-loop/fn
               session.clj:  201  nrepl.middleware.session/session-exec/main-loop
                  AFn.java:   22  clojure.lang.AFn/run
               Thread.java:  825  java.lang.Thread/run

I believe this is because the above dependency has no corresponding jar file, and only contains a pom.xml which groups up a set of dependencies.

Should tools.build functions respect with-dir (from tools.deps.alpha)?

Wed, 08 Sep 2021 22:02:10 +0000

I ran across this issue with depstar but observed that tools.build behaves the same, possibly incorrect, way.

See https://github.com/seancorfield/with-dir-repro

If you wrap (b/create-basis ..) in with-dir from tools.deps.alpha, it calculates the basis from the deps.edn file in the context of the with-dir location.

However, if you use that basis with tools.build functions, they do not behave correctly -- even if they are also wrapped in the same with-dir context.

The dependencies come from the project deps.edn (Clojure 1.9.0 in this example) but the src used is from the root of the repo, not from the project folder.

This is counter-intuitive (and took me a while to track down with depstar -- where I definitely consider it to be a bug).

symbol collision bug in clojurescript?

Thu, 29 Jul 2021 11:01:41 +0000

This this expression in a clojurescript repl:

(let [{:keys [a-b a_b]} {:a-b 0 :a_b 1}] [a-b a_b])

will surprisingly return:

[1 1]

I did some further investigation by creating a clean project like in Clojurescript official guide:

(ns helloworld.core)

;; two identical code blocks

;; first one is at top level
(let [{:keys [a-b a_b]} {:a-b 0 :a_b 1}] [a-b a_b])
;; second one nested inside a function call
(println (let [{:keys [a-b a_b]} {:a-b 0 :a_b 1}] [a-b a_b]))

and compiled with:

clj -M --main cljs.main --compile helloworld.core

here's the js file:

// Compiled by ClojureScript 1.10.866 {:optimizations :none}
goog.provide('helloworld.core');
goog.require('cljs.core');
var map__528_529 = new cljs.core.PersistentArrayMap(null, 2, [new cljs.core.Keyword(null,"a-b","a-b",-1660985764),(0),new cljs.core.Keyword(null,"a_b","a_b",-1795286609),(1)], null);
var map__528_530__$1 = cljs.core.__destructure_map.call(null,map__528_529);
var a_b_531 = cljs.core.get.call(null,map__528_530__$1,new cljs.core.Keyword(null,"a-b","a-b",-1660985764));
var a_b_532 = cljs.core.get.call(null,map__528_530__$1,new cljs.core.Keyword(null,"a_b","a_b",-1795286609));
new cljs.core.PersistentVector(null, 2, 5, cljs.core.PersistentVector.EMPTY_NODE, [a_b_531,a_b_532], null);
cljs.core.println.call(null,(function (){var map__533 = new cljs.core.PersistentArrayMap(null, 2, [new cljs.core.Keyword(null,"a-b","a-b",-1660985764),(0),new cljs.core.Keyword(null,"a_b","a_b",-1795286609),(1)], null);
var map__533__$1 = cljs.core.__destructure_map.call(null,map__533);
var a_b = cljs.core.get.call(null,map__533__$1,new cljs.core.Keyword(null,"a-b","a-b",-1660985764));
var a_b = cljs.core.get.call(null,map__533__$1,new cljs.core.Keyword(null,"a_b","a_b",-1795286609));
return new cljs.core.PersistentVector(null, 2, 5, cljs.core.PersistentVector.EMPTY_NODE, [a_b,a_b], null);
})());

//# sourceMappingURL=core.js.map

as you can see:

the a-b and a_b symbols in first block ended up as var a_b_531 and var a_b_532.
in the second block they both ended up as var a_b, therefore their values collided.

I also get the same result with macroexpanded version using cljs.core/let*

(let* [m {:a-b 0, :a_b 1}
       a-b
       (cljs.core/get m :a-b)
       a_b
       (cljs.core/get m :a_b)]
  [a-b a_b])

(println 
 (let* [m {:a-b 0, :a_b 1}
        a-b
        (cljs.core/get m :a-b)
        a_b
        (cljs.core/get m :a_b)]
   [a-b a_b]))

so we can eliminate the case that something is wrong with cljs.core/let macro

tools.build create-basis cannot use alias that includes tools.deps.alpha

Mon, 26 Jul 2021 23:38:47 +0000

If you try to call create-basis with an alias that involves tools.deps.alpha, you get the following exception:

Execution error (ExceptionInfo) at clojure.tools.deps.alpha.extensions.maven/get-artifact (maven.clj:133).
Could not find artifact org.clojure:tools.deps.alpha:jar:${project.version} in central (https://repo1.maven.org/maven2/)

This is because tools.build includes a source version of deps.edn with that string, instead of a version number:

./tools.build/src/main/resources/clojure/tools/deps/deps.edn
    :deps {:extra-deps {org.clojure/tools.deps.alpha {:mvn/version "${project.version}"}}}

Here's the minimal repro: in an otherwise empty directory:

;; deps.edn 
{:aliases
 {:build
  {:deps {io.github.clojure/tools.build {:git/tag "v0.1.6" :git/sha "5636e61"}}
   :ns-default build}}}

;; build.clj 
(ns build
  (:require [clojure.tools.build.api :as b]))

(defn bug [_]
  (b/create-basis {:aliases [:deps]}))

Then run:

clojure -T:build bug

Given that tools.build already explicitly depends on t.d.a as follows, I don't understand why it also needs a copy of t.d.a's deps.edn source in in the resources tree?

org.clojure/tools.deps.alpha {:mvn/version "0.12.1003"}

Removing that file from the checked out tools.build (under ~/.gitlibs/libs) seems to solve the problem and doesn't appear to break anything else...

Bug when using nested sorted maps

Fri, 26 Mar 2021 08:47:17 +0000

After discussing it on Slack, the following definitely feels like a bug. At the very least, it throws weirdly in CLJS while it is perfectly (and intuitively) fine in Clojure JVM.

(def tree
     (sorted-map 3
                 (sorted-map 1
                             {:a 'leaf-A})))
(def subtree
     (sorted-map 1
                 (sorted-map 100
                             {:b 'leaf-B})))
;; Fine, of course, but now...
(assoc tree
       3
       subtree)
;; Throws:   Error: Cannot compare :a to 100

Andy Fingerhut pointed to a difference in implementation. Clojure compares by reference and CLJS by value, forcing a deep comparison. Even then, I find the error cryptic and argue that logically speaking, Clojure makes sense.

Citing him, Clojure implementation:

https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/PersistentTreeMap.java#L132

And CLJS implementation:

https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/core.cljs#L8857

Is there something we didn't see?

Possible reflection bug with Abstract Base Class methods not being visible

Fri, 08 Jan 2021 09:00:02 +0000

repro.clj:

(defn create-application []
  (let [credential (com.microsoft.aad.msal4j.ClientCredentialFactory/createFromSecret "sekrit")
        builder (com.microsoft.aad.msal4j.ConfidentialClientApplication/builder "client id" credential)
        authority "some authority"]
    (->
      builder
      (.authority ^String authority)
      (.build))))

(create-application)

Run with:

clj -Sdeps '{:deps {com.microsoft.azure/msal4j {:mvn/version "1.8.1"}}}' repro.clj

The source code for the concrete class is at https://github.com/AzureAD/microsoft-authentication-library-for-java/blob/dev/src/main/java/com/microsoft/aad/msal4j/ConfidentialClientApplication.java

And the base class is at https://github.com/AzureAD/microsoft-authentication-library-for-java/blob/dev/src/main/java/com/microsoft/aad/msal4j/AbstractClientApplicationBase.java where the authority field is declared with a Lombok Accessor annotation...

Using eval from cljs.js with webpack

Sun, 03 Jan 2021 02:57:09 +0000

In clojurescript 1.10.773 it is impossible to use eval from cljs.js when I've bundled the project with webpack I think this is because eval is calling find-ns-obj, when doesn't work with the :bundle :target. That makes sense, but this error still occurs when an :ns is passed in the options map.

Using eval from cljs.js used to work in clojurescript 1.10.741, even when :target was set to :bundle. It looks like this is because previous versions of clojurescript never set *target* when it was set in the compiler options.

The error I'm getting is:

core.cljs:11642 Uncaught Error: find-ns-obj not supported for target bundle
    at Object.cljs$core$find_ns_obj [as find_ns_obj] (core.cljs:11642)
    at Function.cljs$core$IFn$_invoke$arity$1 (core.cljs:11660)
    at cljs$core$create_ns (core.cljs:11657)
    at Function.cljs$js$compile_str_STAR__$_compile_loop (js.cljs:918)
    at Function.cljs$core$IFn$_invoke$arity$3 (core.cljs:3918)
    at Function.cljs$core$IFn$_invoke$arity$2 (core.cljs:3913)
    at Function.cljs$core$IFn$_invoke$arity$2 (core.cljs:3948)
    at core.cljs:10831
    at Function.cljs$core$IFn$_invoke$arity$1 (core.cljs:10826)
    at Function.cljs$core$IFn$_invoke$arity$variadic (core.cljs:10831)
cljs$core$find_ns_obj @ core.cljs:11642
(anonymous) @ core.cljs:11660
cljs$core$create_ns @ core.cljs:11657
cljs$js$compile_str_STAR__$_compile_loop @ js.cljs:918
(anonymous) @ core.cljs:3918
(anonymous) @ core.cljs:3913
(anonymous) @ core.cljs:3948
(anonymous) @ core.cljs:10831
(anonymous) @ core.cljs:10826
(anonymous) @ core.cljs:10831
cljs$core$trampoline @ core.cljs:10817
cljs$js$compile_str_STAR_ @ js.cljs:910
(anonymous) @ js.cljs:1019
cljs$js$compile_str @ js.cljs:968
interactive_syntax$core$eval_str @ core.cljs:48
run @ core.cljs:351
callCallback @ react-dom.development.js:188
invokeGuardedCallbackDev @ react-dom.development.js:237
invokeGuardedCallback @ react-dom.development.js:292
invokeGuardedCallbackAndCatchFirstError @ react-dom.development.js:306
executeDispatch @ react-dom.development.js:389
executeDispatchesInOrder @ react-dom.development.js:414
executeDispatchesAndRelease @ react-dom.development.js:3278
executeDispatchesAndReleaseTopLevel @ react-dom.development.js:3287
forEachAccumulated @ react-dom.development.js:3259
runEventsInBatch @ react-dom.development.js:3304
runExtractedPluginEventsInBatch @ react-dom.development.js:3514
handleTopLevel @ react-dom.development.js:3558
batchedEventUpdates$1 @ react-dom.development.js:21871
batchedEventUpdates @ react-dom.development.js:795
dispatchEventForLegacyPluginEventSystem @ react-dom.development.js:3568
attemptToDispatchEvent @ react-dom.development.js:4267
dispatchEvent @ react-dom.development.js:4189
unstable_runWithPriority @ scheduler.development.js:653
runWithPriority$1 @ react-dom.development.js:11039
discreteUpdates$1 @ react-dom.development.js:21887
discreteUpdates @ react-dom.development.js:806
dispatchDiscreteEvent @ react-dom.development.js:4168
Show 8 more frames
react-dom.development.js:327 Uncaught Error: find-ns-obj not supported for target bundle
    at Object.cljs$core$find_ns_obj [as find_ns_obj] (core.cljs:11642)
    at Function.cljs$core$IFn$_invoke$arity$1 (core.cljs:11660)
    at cljs$core$create_ns (core.cljs:11657)
    at Function.cljs$js$compile_str_STAR__$_compile_loop (js.cljs:918)
    at Function.cljs$core$IFn$_invoke$arity$3 (core.cljs:3918)
    at Function.cljs$core$IFn$_invoke$arity$2 (core.cljs:3913)
    at Function.cljs$core$IFn$_invoke$arity$2 (core.cljs:3948)
    at core.cljs:10831
    at Function.cljs$core$IFn$_invoke$arity$1 (core.cljs:10826)
    at Function.cljs$core$IFn$_invoke$arity$variadic (core.cljs:10831)

Any use of eval, or eval-str, compile-str, etc. gives it to me. Say:

(eval-str (empty-state) "(+ 1 2)" "UNTITLED" {:eval js-eval} println)

And I get this error even if I provide my own :ns.

Function with meta equality fails

Wed, 23 Dec 2020 16:08:44 +0000

Bug report:

(defn f [] 1)
=> #'cljs.user/f
(= f (with-meta f {:a 1}))
=> false ;; should be true

Per: https://clojure.org/reference/metadata
"metadata does not impact equality"

Suspected bug in `clojure.core/partition`

Thu, 10 Dec 2020 02:54:45 +0000

2 problems:
- The docstring of clojure.core/partition is not clear on what "last partition" means.
- The behavior of partition is strange, IHMO it has a bug.

Please take a look at this:

(partition 3 1 [:a :b :c] (range 5))

; actual behavior
; => ((0 1 2) (1 2 3) (2 3 4) (3 4 :a))

; expected behavior, option 1
; => ((0 1 2) (1 2 3) (2 3 4))

; expected behavior, option 2
; => ((0 1 2) (1 2 3) (2 3 4) (3 4 :a) (4 :a :b))

I would expect the "last partition" to be defined as:

The last partition to contain elements from the input collection (not the padding collection) which are not present in any previous partition.

This is consistent with option 1 above.