ClojureCLR: Clojure on the CLR, packaged as a library you can embed

Two deployment modes, and the choice is the whole point

ClojureCLR can run as a standalone application or embedded as a library inside a .NET application. That sentence in the README is short, but it separates ClojureCLR from every other way of running Clojure on Windows, because the embedded case means Clojure code runs inside the same process and the same runtime as the rest of your .NET services, with no sidecar JVM and no second runtime to deploy.

The runtime underneath is the Common Language Runtime, described in the README as the execution engine of Microsoft's .Net Framework. The implementation language is C# and Clojure itself, so the port is not a transpiler that emits C# from Clojure source and throws the source away; the runtime is a real implementation written in both languages.

The stated goals are worth reading in order, because they explain the project's trade-offs. Feature completeness on top of the CLR comes first. Staying as close as possible to the JVM implementation comes second, which is the constraint that governs almost every design decision that looks different from what a JVM Clojure developer expects. The third goal is simply to have some fun.

The documentation you need is mostly inherited, with a wiki for the rest

The README makes an unusual and honest claim about documentation: most of the documentation for Clojure should be equally applicable to ClojureCLR. That is a direct statement about the design, because it is only true if the port tracks the JVM implementation closely. When something is different on the CLR, it is by definition a place where the JVM documentation misleads you.

ClojureCLR-specific documentation lives in two places. There is a wiki linked from the README, and there are articles under a docs directory in the repository. The wiki also carries a getting started guide, which is where the installation, run and integration instructions are.

That last point is a practical constraint for anyone evaluating the project. The README gives no install command, no dotnet command and no NuGet package name, so there is nothing here to copy into a terminal. Following the getting started guide is not optional if you intend to build or run anything, and anyone writing an evaluation summary that skips that step will have to leave the build model blank.

Libraries are the adoption question, and there is a separate list for them

The README states that many of the standard libraries from JVM Clojure have CLR ports, and links to a repository search covering them. The word that carries the meaning is many, not all. A ClojureCLR project inherits the JVM library ecosystem only to the extent that someone has ported the parts it uses.

This is the constraint that decides whether ClojureCLR works for you, and it is worth resolving before anything else. Take the libraries your existing code already imports, check each one against the CLR port list, and count how many have no equivalent. One missing transitive dependency in a build chain can be enough to end the evaluation, and the failure tends to surface late, when someone adds a namespace that nobody checked.

The ports are also a maintenance question rather than a one-off. A port in a different repository follows its own release cadence and its own maintainer, so an upgrade of a core library does not necessarily bring its ports with it.

Issue tracking goes through JIRA and a contributor agreement

Support for ClojureCLR is split across three channels, and the issue tracker is the one with a catch. The project uses ClojureCLR JIRA for issue tracking, hosted in the Clojure Atlassian instance, and the README notes that creating an issue there requires signing a contributor agreement.

That requirement changes who can report a bug. A user with a crash in an embedded ClojureCLR instance may not want to, or be able to, sign a contributor agreement, and the README's own advice is that minor issues might be easier to raise on Slack instead. For questions rather than bugs there is the #clr channel in the Clojurians Slack and the ClojureCLR category on Ask Clojure.

The practical division is: Slack for quick questions, Ask Clojure for things worth writing up, and JIRA for tracked issues, knowing that JIRA asks for a signature first. Anyone planning to use ClojureCLR commercially should note that the agreement requirement applies to the reporting path, and check what signing means for their organisation before they need it.

EPL 1.0 is a different licence from the one most Clojure users expect

The licence is stated in the README rather than in a LICENSE file, and the top level entries include epl-v10.html as the actual text. Copyright is held by Rich Hickey, and the distribution terms are the Eclipse Public License 1.0.

EPL 1.0 is a file-level copyleft licence, which behaves differently from both the Apache and MIT licences more common in this ecosystem. It is not the same as GPL, and it is not permissive. The obligations attach to modified files of the covered software rather than to your entire application, so linking your own code to ClojureCLR does not in itself oblige you to release that code. This paragraph is a description of the terms, not legal advice, and the epl-v10.html file at the root is the authoritative text for anyone with a formal compliance process.

One obligation is stated explicitly and is easy to honour: you must not remove the copyright notice, or any other notice, from the software. If you redistribute ClojureCLR, in binary or source form, keep epl-v10.html and the notice with it.

What the repository layout says about the build

The top level of the repository reads like a build system rather than a documentation site. There is Clojure.nuspec, which is a NuGet package specification, alongside a Clojure/ directory holding the implementation, an other/ directory, a changes.md file that serves as the changelog, CONTRIBUTING.md, and.gitmodules, which means parts of the tree arrive as git submodules rather than as tracked files. A.calva/ directory is also present, and

The changes.md file is where a returning user should look first. With no GitHub releases published, there is no tag-based release history to diff against, so the changelog file is the only in-repository record of what changed and when.

For the.NET ecosystem specifically, the presence of a nuspec tells you the packaging path goes through NuGet rather than only through a build-from-source model. The README does not state a package identifier, so treat that as something to confirm in the getting started guide rather than an established fact.

Editorial conclusion

Adopt ClojureCLR when you need Clojure semantics inside an existing .NET process, since the embedded mode is what distinguishes it from running a JVM alongside your services. Do not adopt it if your dependency set is JVM-only: many standard Clojure libraries have CLR ports but not all do, and the README links a separate repository list for them. Verify first, before writing a line, which libraries your code needs exist as CLR ports, and read the ClojureCLR wiki rather than the JVM docs for anything touching interop, since the project states that most Clojure documentation applies but not all of it.

Frequently asked questions

Official sources

1. clojure/clojure-clr on GitHub
2. Issues
3. README