Clojurians Log v2

Is it possible to leverage this wild thing to use jvm related tools or libraries in ClojureCLR?

"possible" carries a lot of freight. Just a brief contemplation of how to make it work makes my head hurt. Let's say you have a Clojure library that has not been modified to run on ClojureCLR. So you AOT-compile that so we have something for IKVM to chew on. If it needs to modification to run on ClojureCLR, that means you have Java interop. IKVM does come with .NET implementations of the Java class libraries, so that might be enough. Well, not really. An AOT-compiled library has an initialization class with a method that implements the process of loading the library -- creating the namespace, defining the Vars implied by all the def-whatevers, interning them in the namespace. That's all implemented as calls into Clojure(JVM) internals. So one can hope that ClojureCLR implements all those classes and methods with exactly the same names and interfaces. That's mostly true. There is a class clojure.lang.Var, and it has an intern method with the proper arguments, for example. But is it true enough to get you through loading the library? All you need is one place where ClojureCLR used an uppercase naming convention, or used a property instead of field get/set, to throw things off. One could try to also pull in the entire ClojureJVM ecosystem via IKVM. You could not just pull in part of it -- the code has circularities beyond counting. Now you will have some serious problems with name clashes. Two versions of clojure.lang.Var . Now, .NET can handle two classes with the same namespace-qualified name -- they just have to be in different assemblies. But how do you get the initialization code to call the ClojureJVM version instead of a ClojureCLR version? There is no assembly information in the JVM bytecode. I'm not sure how you rig IKVM to deal with this. That's just off the top of my head. I don't know if it is accurate. Go for it. Oh, another possibility. Don't start with the AOT-compiled JVM library. Pull the ClojureJVM compiler into .NET and load the library through there. That would require IKVM to translate dynamically generated bytecode. I have no idea if it can manage that. If you try that, please give advance warning so I can relocate to Mars.

I think pure Java libraries through IKVM is interesting (with the limitation of max classfile version number 52 i.e. they need to have been compiled with java 8 ) . But in terms of Clojure code you might just want to use reader conditionals (.cljc files).

However, having said all that, technically you can run ClojureJVM inside .NET. Whether you should is a good question! I have no idea what the limitations are but at least it starts, offers a socket repl and does arithmetic. https://gist.github.com/jamesdavidson/d8edca06d83e2786c87dbcd755465906

Given the question was about using tools/libraries with ClojureCLR, I did not address just running ClojureJVM directly without ClojureCLR. Very cool that it works. It would be interesting to know more about possible limitations. If you get RT to init, that's loading all of the clojure core, + spec. Can you run the main repl? Compile a file? One might want to interop with CLR libraries -- a fair assumption if you want to run .NET instead of the JVM. What else can we think of? If no limitation, no need for ClojureCLR? Unity achieved? IKVM has been around roughly forever. I remember it being brought up in the early days, maybe 13-14(?) years ago. I don't know if it was found not up to the task at that point. Could just have been that no one put in the effort. Certainly no one came up with any kind of proof of concept in the way you have. (That I know of.)