Skip to content

Extend Expand to APersistentMap on JVM - #794

Merged
opqdonut merged 2 commits into
metosin:masterfrom
The-Alchemist:expand-apersistent-map
Sep 17, 2026
Merged

opqdonut merged 2 commits into
metosin:masterfrom
The-Alchemist:expand-apersistent-map

Conversation

@The-Alchemist

@The-Alchemist The-Alchemist commented Sep 4, 2026 •

Copy link
Copy Markdown
Contributor

Summary

  • On JVM, extend reitit.core/Expand to clojure.lang.APersistentMap instead of the concrete PersistentArrayMap / PersistentHashMap classes.

Behavior for stock Clojure maps is unchanged (expand still returns this). Protocol dispatch continues to cache per concrete class after first resolve.

This keeps route-data map expansion working for any APersistentMap subclass (e.g. PersistentTreeMap, and alternate JVM Clojure runtimes that provide their own map implementations under that hierarchy), without requiring library-specific reader features.

Reason

Cloffle is a GraalVM/Truffle Clojure runtime with specialized map types that extend APersistentMap but not PersistentArrayMap / PersistentHashMap. Extending those concrete classes means Cloffle map literals miss Expand; targeting APersistentMap fixes that without changing stock Clojure behavior.

We use reitit as part of our compatibility tests with Clojure, and we maintain this patch for reitit internally. This PR would help us avoid that, without any performance impact on reitit itself.

Cover all APersistentMap subclasses (including alt-runtime map
impls) without naming concrete ArrayMap/HashMap classes. CLJS
keeps the existing concrete map extensions.

Signed-off-by: Karl Pietrzak <karl@medplum.com>
@The-Alchemist
The-Alchemist marked this pull request as ready for review September 4, 2026 13:58

#?(:clj clojure.lang.PersistentHashMap
:cljs cljs.core.PersistentHashMap)
#?(:cljs cljs.core.PersistentHashMap)

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

hmm: how is this syntactically valid in the clj case? shouldn't the next line be inside the #? guard as well?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i won't pretend to understand the details of the #?(:clj and #?(:cljs) conditionals, but i made a few tweaks: fb92a9f

should be easier to read, and added a test case for good measure.

let me know what you think!!

Signed-off-by: Karl Pietrzak <karl@medplum.com>

@opqdonut opqdonut left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

golden, thanks

@opqdonut
opqdonut merged commit d8a6df4 into metosin:master Sep 17, 2026
11 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: ✅ Done

Development

Successfully merging this pull request may close these issues.

2 participants