Clojurians Log v2
clr
A big question: Is support for ClojureCLR on Framework 4.x still needed?
Having noted the recent decision to drop Java 8 on the JVM side, I thought I'd ask the question.
Framework 4.x may never go away. 4.8.1 was released in 2022 with no end date. (According to one source, its end date might be tied to the end of of support for the OS it's on. The latest release of Windows 11 Server includes it and its lifetime (for IoT Enterprise) is through 2034. Do NOT ask how old I'll be in 2034.)
I kept support going in the past because I knew of at least one project that used it. I have selfish reasons for wanting to drop support, including:
• Staying up to date. This is at both the library and compiler level. Framework 4.x keeps me programming in C# 7.3. This has costs -- there are some compiler enhancements with performance implications. And since in the rest of my life I'm coding in C# 13, I have to switch modes mentally every time I come back to Clojure. I'm pretty sure there are some library enhancements that are not .netstandard 2.0 that I could tap into. (At present, Code Analysis in VS suggests 1784 improvements to code. Sigh.)
• Complexity. We lost AOT compilation of Clojure source with the advent of .NET Core 3. With .NET Core 9, we once again have the ability to write dynamically created assemblies to file. However, this is going to require different coding of the mechanics of AssemblyBuilder handling. For example, a subclass of AssemblyBuilder is required. I'm not sure what other changes I am going to have to make to code-gen mechanics, but all that will have to be conditionalized.
Looking for feedback. @alexmiller: of course, should the high council have an opinion, I will follow that direction.
By the way, .NET 6 is no longer supported by Microsoft. ClojureCLR might want to stop targeting it at some point.
The last patch release was on 2024.11.12, which date was also the End-of-support date. I figure some folks may still take a while to move. (I have a client I've been nudging for a year to move from .Net 6 to .Net 8, since .Net 8 was officially released. They start testing on 8 next week.) I'll give it at least another 6 months.
I put explicit assembly loads in certain .clj source files.
Solves the problem.
Wwwaaayyy too much time on this one.
If you drop support for it, what are the implications for Clojure users? They'd have to (manually) install a later version of .NET or something?
(a) Keep using the version of ClojureCLR for Framework 4.x that exists now. Just not likely to see updates. That being said, most Clojure-sourced library developments would be available. (b) Update to a later version of .NET. I have no idea the extent of Framework 4.x ClojureCLR in the real world. For hobby projects, presumably upgrading .NET is not such a big deal. The number of business projects is unknown. The ones I've talked to our not on Framework. The only exception uses a bespoke version of ClojureCLR on 4.x already that requires hand modification. They will sit tight on it until the underlying tool upgrades to a new version of .NET, a process that is underway.
So... that sounds like it wouldn't really be a big deal to drop Framework at this point?
I don't know what I don't know.
For what it is worth, you can actually increase your C# version while supporting .NET Framework 4.8. For example at work we have this:
net48;net8.0-windows
12.0 That said, I don't use Clojure CLR on framework myself. (But I'm interested in trying it out more on .NET 8 and so on.)
I'm interested. Just for the possibility of moving forward and also not dropping support for Framework if not too much effort. I know I'll have to conditionalize to bring back AOT on .NET 9, but maybe I can isolate that effectively.
@dmiller found them, here it is: https://gist.github.com/isaksky/fecc4f897083d453a1e66ee34bd0eaf0 (I'm sure it is not 100% support btw.)
Thanks much. That will get me started enough to judge feasibility.
We’re using ClojureCLR in a Plugin for Autodesk Revit, Revit has only moved from .NET Framework 4.8 (to .NET 8) in the latest 2025 release. Since most users are still using Revit 23/24, we’ll probably need to build for 4.8 for about 2 years.
In that case, I'll keep you going one way or another. That's what I needed to know. I'd love to hear more about the project some time, if you're willing.
I never got so far as changing the compiler version. Going into the Clojure project itself, Clojure.csproj has
<TargetFrameworks>netstandard2.1;net462</TargetFrameworks><TargetFrameworks>net6.0;net8.0;net9.0;net462</TargetFrameworks>core.clj and nine other .clj library files. Then it tries to load :imports blows up. And, yes, folks, we have a heisenbug.
If I throw a breakpoint in on the method that loads .clj files, the error goes away and the REPL comes up, no problem.
I'm going to go cry myself to sleep.
I was incorrect. .Net 6.0 also blows up.
.Net 6.0 blows up because it can't find the type System.Runtime.InteropServices.RuntimeInformation.
.Net 8/9 blow up because they can't find
you are the high council of ClojureCLR :) I certainly have way less context. I think that you should do what you need to do to move the world forward - existing projects can continue using older versions if needed.
Thanks. I prefer the title "factotum".
FYI https://ask.clojure.org/index.php/14284/clr-behavior-tools-namespace-does-not-match-implementation (not sure how closely you follow ask @dmiller?)
this came from a thread farther up in the back chat
Thanks. Missed that.