Dans quelle mesure Clojure est-il indépendant de Java?

Je suis assez nouveau dans le monde Clojure. J'apprécie le fait que l'on ait un accès facile à toutes les bibliothèques Java via les fonctionnalités d'interopérabilité de Clojure, mais je me demandais combien Clojure se tenait sur ses propres jambes.

Bien sûr, il existe certaines plates-formes, comme Android, où l'interopérabilité avec Java sera toujours nécessaire, car les bibliothèques principales sont écrites ou exposées en Java. De plus, comme les chaînes Clojure sont des chaînes Java, je m'attends à ce que les bibliothèques de manipulation de chaînes soient un wrapper sur les méthodes Java String.

Mais pour d'autres tâches, je ne vois aucune raison pour laquelle les bibliothèques natives Clojure n'ont pas pu être développées. Pensez à Http, à la manipulation de dates, à l'analyse XML, aux modèles, à la sérialisation et à la désérialisation JSON, à OAuth, aux bibliothèques mathématiques, etc.

Ma question est donc:

Dans quelle mesure Clojure est-il devenu indépendant de l'écosystème Java? A-t-il ses propres bibliothèques idiomatiques pour la plupart de ces tâches et d'autres?

Clojure devient de plus en plus indépendant des bibliothèques Java à mesure que sa base de code se développe et se diversifie naturellement. Une force majeure de Clojure est qu'il peut appeler Java, donc voir du code Clojure à l'avenir qui n'utilise pas java serait peu probable. Cela étant dit, j'ai fait beaucoup de développement sans appeler de bibliothèques Java (arguments de ligne de commande, minupulation de texte de base, etc.). Voici une liste de bibliothèques clojure pures: http://www.clojure-toolbox.com/

Je pense qu'il est juste de dire que Clojure est conçu comme un langage hébergé et qu'il a maintenant trois implémentations:

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

Parce qu'il est conçu comme un langage hébergé, l'idiome est de tirer parti des bibliothèques de la plate-forme sous-jacente là où cela a du sens, mais également de fournir un ensemble de bibliothèques "de base" qui sont portables (à partir d'un point de vue d'utilisation, pas nécessairement au niveau du code). J'espère qu'au fil du temps, nous verrons beaucoup plus de bibliothèques Clojure s'exécuter sur les trois plates-formes, là où cela aura du sens.

Je maintiens clojure.java.jdbc et clj-time (un wrapper autour de JodaTime), il n'est donc pas logique de les utiliser sur les versions * CLR ou * Script, mais des bibliothèques compatibles API dans différents espaces de noms pourraient être une possibilité.

La plupart des bibliothèques Clojure "pures" devraient être faciles à utiliser sur les versions * CLR ou * Script déjà.

À la question de l'OP: "Clojure-the-language" est assez portable mais "Clojure-the-implementation" est délibérément lié à l'écosystème Java, tout comme ClojureCLR à .NET et ClojureScript à JavaScript.

Comme Clojure continue d'évoluer, il va certainement construire de plus en plus de ses propres bibliothèques, permettant des ports plus faciles vers d'autres machines virtuelles. En ce qui concerne Clojure sur la JVM, je pense que l'objectif à long terme sera de remplacer la plupart des bibliothèques par des alternatives à Clojure (ayant ainsi cette immuabilité par défaut, STM, etc.), ramenant la couche d'interopérabilité Java au plus bas niveau de primitives et de base des objets tels que String. Cela sera particulièrement vrai une fois que la plate-forme Java sera modularisée avec Jigsaw / OSGi dans Java 8 (2013).

Cependant, je crois que Clojure voudra toujours essayer de tirer parti de la dynamique invoquée (introduite comme une instruction de bytecode dans Java 7) et adoptera une approche assez pragmatique sur les bibliothèques à remplacer quand (si Java a une bibliothèque parfaitement bonne, alors pourquoi changer tôt).

NOTE: Je ne suis pas profondément impliqué dans la communauté Clojure, donc c'est en partie du ouï-dire / des conjectures.