I am quite new to the Clojure world. I appreciate the fact that one has easy access to all Java libraries via Clojure interop features, but I was wondering how much Clojure stands on its own legs.

Of course there are some platforms, like Android, where interoperability with Java will always be required, because the core libraries are written or exposed in Java. Moreover, since Clojure strings are Java strings, I expect string manipulation libraries to be a wrapper on the Java String methods.

But for other tasks I see no reason why native Clojure libraries couldn't be developed. Think of Http, date manipulation, XML parsing, templating, JSON serialization and deserialization, OAuth, math libraries and so on.

So my question is:

How far has Clojure come to become independent of the Java ecosystem? Does it have its own idiomatic libraries for most of these and other tasks?

  • ClojureCLR is a Clojure port to the .Net framework. – S.L. Barth Jan 18 '12 at 9:01
  • 1
    For my taste, too much of the Clojure core is implemented in Java, it is not bootstrapped properly. – SK-logic Jan 18 '12 at 9:07
  • @Barth: I know ports to other platforms exist, but this does not tell much about the question. It could run on the CLR and still not have its own libraries. – Andrea Jan 18 '12 at 9:16
  • 1
    @JeremyHeiler, of course anyone in a sound mind would try to achieve such a goal. The question is - why Clojure was not implemented this way from the very beginning? It's so much easier than coding a compiler in Java. – SK-logic May 23 '12 at 18:22
  • 1
    @SK-logic, From what I can tell, the features that Rich Hickey wanted in order to bootstrap Clojure properly have taken time to come to fruition. That is, he didn't want to rush design decisions that could adversely affect the language, decisions that could potentially yield better results if more time was spent on thinking about how certain features could work. Maybe I am completely off, but that is my take on the subject. – Jeremy Heiler May 23 '12 at 18:53

Clojure is becoming more and more independent of Java libraries as its code base grows and naturally diversifies. A major strength of Clojure is that it can call Java, so to see Clojure code in the future that doesn't use java would be unlikely. That being said, I have done a good deal of development w/o calling Java libs(command line args, basic text minupulation, etc). Here's a list of pure clojure libraries: http://www.clojure-toolbox.com/

  • I have chosen this answer thanks to the link to a repository of pure Clojure libraries. – Andrea Jan 22 '12 at 12:17

I think it's fair to say that Clojure is designed as a hosted language and it now has three implementations:

  • Clojure on JVM
  • ClojureCLR on .NET
  • ClojureScript on JavaScript

Because it is designed as a hosted language, the idiom is to leverage the underlying platform's libraries where it makes sense but also provide a set of "core" libraries that are portable (from a usage p.o.v., not necessarily at the code level). I expect over time we'll see a lot more Clojure libraries running on all three platforms, where it makes sense.

I maintain clojure.java.jdbc and clj-time (a wrapper around JodaTime) so it doesn't make sense to use those on the *CLR or *Script versions but API-compatible libraries in different namespaces might be a possibility.

Many of the "pure" Clojure libraries should be straightforward to use on the *CLR or *Script versions already.

To the OP's question: "Clojure-the-language" is pretty portable but "Clojure-the-implementation" is deliberately bound to the Java ecosystem, as is ClojureCLR to .NET and ClojureScript to JavaScript.


As Clojure continues to evolve it will certainly build more and more of its own libraries, allowing for easier ports to other VMs. As far as Clojure on the JVM is concerned I believe the long term goal will be to replace most libs with Clojure alternatives (thereby having that immutability by default, STM etc), bringing the Java interop layer down to the lowest level of primitives and base objects such as String. This will especially true once the Java platform is modularised with jigsaw/OSGi in Java 8 (2013)

However, I believe that Clojure will still want to try and take advantage of invokedynamic (introduced as a bytecode instruction in Java 7) and will take a fairly pragmatic approach about which libraries to replace when (if Java has a perfectly good lib, then why change it early).

NOTE: I'm not involved deeply in the Clojure community, so this is partly hearsay/guesswork.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.