Wie unabhängig ist Clojure von Java?

Ich bin ziemlich neu in der Clojure-Welt. Ich schätze die Tatsache, dass man über Clojure-Interop-Funktionen leicht auf alle Java-Bibliotheken zugreifen kann, aber ich habe mich gefragt, wie viel Clojure auf seinen eigenen Beinen steht.

Natürlich gibt es einige Plattformen wie Android, für die immer eine Interoperabilität mit Java erforderlich ist, da die Kernbibliotheken in Java geschrieben oder verfügbar gemacht werden. Da es sich bei Clojure-Strings um Java-Strings handelt, erwarte ich außerdem, dass die String-Manipulationsbibliotheken ein Wrapper für die Java-String-Methoden sind.

Aber für andere Aufgaben sehe ich keinen Grund, warum native Clojure-Bibliotheken nicht entwickelt werden konnten. Denken Sie an HTTP, Datumsmanipulation, XML-Analyse, Templating, JSON-Serialisierung und -Deserialisierung, OAuth, Mathematikbibliotheken und so weiter.

Meine Frage lautet also:

Inwieweit ist Clojure vom Java-Ökosystem unabhängig geworden? Verfügt es über eigene Sprachbibliotheken für die meisten dieser und anderer Aufgaben?

Clojure wird immer unabhängiger von Java-Bibliotheken, da seine Codebasis wächst und sich auf natürliche Weise diversifiziert. Eine große Stärke von Clojure ist, dass es Java aufrufen kann. Daher ist es unwahrscheinlich, dass in Zukunft Clojure-Code ohne Java angezeigt wird. Davon abgesehen habe ich viel entwickelt, ohne Java-Bibliotheken aufzurufen (Befehlszeilenargumente, Minupulation von Basistexten usw.). Hier ist eine Liste von reinen Clojure-Bibliotheken: http://www.clojure-toolbox.com/

Ich denke, es ist fair zu sagen, dass Clojure als gehostete Sprache entworfen wurde und jetzt drei Implementierungen hat:

• Clojure auf JVM
• ClojureCLR unter .NET
• ClojureScript in JavaScript

Da es als gehostete Sprache konzipiert ist, besteht die Redewendung darin, die Bibliotheken der zugrunde liegenden Plattform zu nutzen, sofern dies sinnvoll ist, aber auch eine Reihe von "Kern" -Bibliotheken bereitzustellen, die portierbar sind (ausgehend von einer Verwendungsstrategie, nicht unbedingt auf Codeebene). Ich gehe davon aus, dass mit der Zeit viel mehr Clojure-Bibliotheken auf allen drei Plattformen laufen werden, sofern dies sinnvoll ist.

Ich verwalte clojure.java.jdbc und clj-time (ein Wrapper um JodaTime), daher ist es nicht sinnvoll, diese in den Versionen * CLR oder * Script zu verwenden, aber API-kompatible Bibliotheken in verschiedenen Namespaces könnten eine Möglichkeit sein.

Viele der "reinen" Clojure-Bibliotheken sollten in den * CLR- oder * Script-Versionen bereits problemlos zu verwenden sein.

Auf die Frage des OP: "Clojure-the-language" ist ziemlich portabel, aber "Clojure-the-Implementation" ist bewusst an das Java-Ökosystem gebunden, ebenso wie ClojureCLR für .NET und ClojureScript für JavaScript.

Da sich Clojure weiterentwickelt, wird es mit Sicherheit immer mehr eigene Bibliotheken aufbauen und so einfachere Ports zu anderen VMs ermöglichen. In Bezug auf Clojure auf der JVM glaube ich, dass das langfristige Ziel darin bestehen wird, die meisten Bibliotheken durch Clojure-Alternativen zu ersetzen (wobei diese standardmäßig unveränderlich sind, STM usw.), wodurch die Java-Interop-Schicht auf die niedrigste Ebene von Grundelementen und Basis gebracht wird Objekte wie String. Dies gilt insbesondere dann, wenn die Java-Plattform mit Jigsaw / OSGi in Java 8 (2013) modularisiert wurde.

Ich bin jedoch der Meinung, dass Clojure weiterhin versuchen wird, die Vorteile von invokedynamic (eingeführt als Bytecode-Anweisung in Java 7) zu nutzen, und einen ziemlich pragmatischen Ansatz verfolgen wird, welche Bibliotheken zu ersetzen sind (wenn Java eine perfekte Bibliothek hat, warum?) ändern Sie es früh).

HINWEIS: Ich bin nicht tief in die Clojure-Community involviert, daher ist dies zum Teil eine Vermutung.