Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.


  • The compiler will need a standard way to determine which variant is active to make decisions during compilation.

Linking Choices

When a ns is compiled, for every call it can make a different linking decision:
  • For other namespaces 
  • For vars in current namespace
  • Perhaps overrides on specific functions - to leave some functions dynamically patchable 


Usage Scenarios

Clojure dyn (AOT)


  • Clojure code is compiled with direct linking
  • Internal calls from one Clojure core function to another cannot be redefined (due to AOT)
    • So, no "monkeypatching" Clojure core internal calls
  • External code can redef calls to core Clojure fns (but only applies to those external calls)
  • Some metadata is trimmed (docstrings) to save space and loading time
    • Things like "doc" would not work
Application dyn
  • Same as now (but use of Clojure core depends on which version you use as above)
Application prod (source) 
  • As source is loaded and compiled, internal references are statically linked
  • External Internal calls to application functions can be redefined 
  • Internal calls to application functions can be 
Clojure prod (AOT) + Application prod AOT


  • redefed?
Application prod (AOT)


Clojure prod (AOT) + Library prod source + Application prod source


How do these scenarios affect what the end Application can do?  How do intermediate libraries choose what they depend on and publicize what they're doing to users? 


  • Application code is compiled with direct linking
  • Application calls to Clojure functions is compiled with direct linking
  • Can redef in scope but all existing internal calls cannot be changed



Maven coordinate options