It's come up a few times in discussions in the past. I think the reason it isn't very compelling for the Clojure CLI is that the version of Clojure itself is completely independent of the CLI version -- you can use Clojure 1.0 with CLI 1.11.1.1347 if you want. If you use Homebrew (Linuxbrew), you can have multiple versions installed and select which version you want by specifying the specific versioned path or env/path vars. I used to do this -- mainly because I was testing a lot of prerelease CLI versions -- but I found that for day-to-day work, I pretty much always wanted the very latest version.

With a lot of these package management systems, there's often an additional complication about a) building everything from a specific version of source and/or b) the dependency on the JDK version. The Homebrew team take the position that you should always depend on the latest versions of things, so they modified the clojure recipe to install the very latest JDK, no matter what you already had installed. 😞 That's why the core team maintain their own tap now (with no explicit JDK dependency). Building everything in the CLI from source is problematic because Clojure core depends on Spec and of course Spec depends on core. So to completely bootstrap Clojure you need to build a pre-Spec version of Clojure core, then use that to build the current version of core and Spec and the core specs. I can't remember for certain, but that itself may be a multi-step process because of changes to core and/or Spec.

I particularly dislike homebrew for how it insists on the latest as the one-true version. Doesn’t seem very sophisticated, and it’s certainly broke plenty of things for me, I prefer MacPorts for that reason and keep it high up on my PATH for it’s higher reliability--and that it does a better job managing correct versioned dependencies. Sounds like a bit of extra loops to change versions with homebrew like that! I would recommend checking out the experience of switching versions of java, say, with sdk and seeing what that’s like from a user perspective; haven’t had such joy from a CLI before, really. I understand the challenges from a vendor/provider side of things, as far as maintaining multiple build pipelines on top of all the other release processes that must exist, which is why I mention as a slight nudge and possible convenience to others new and old alike.

I love SDKMAN. Always use it for Java, and agree it brings an unusual sense of joy.

@U06CV4M88 I have half a dozen JDKs installed and generally use JAVA_HOME=$OPENJDK<N>_HOME as a prefix on a command when I want to run something using specific command (I have a *_HOME env var set up for each since they're not all in obvious places). That way I can do stuff like for j in $OPENJDK11_HOME $OPENJDK14_HOME $OPENJDK17_HOME; do JAVA_HOME=$j some-command; done and run a test against multiple JDKs 🙂 I agree on Homebrew's policies -- but it was useful while I was testing a lot of different CLI prereleases (I had maybe 20 different versions installed?). I guess, also, I'm really old-school and don't really trust a lot of these environment management things 🙂 I've been badly bitten by env managers for Ruby and Python in the past too.

(I also prefer solutions that are essentially portable in terms of commands across platforms -- and I've switched from macOS for dev to Windows/WSL2 over the last few years while our CI/QA/prod systems have been various flavors of Linux)

@U04V70XH6 That makes a lot of sense. For note, SDKMAN maintains all of the various versions under ~/.sdkman/candidates/java` ; so, for instance, an ls of that directory for me looks like 11.0.18-tem 17.0.2-oracle. 17.0.2-zulu. 17.0.5-tem. 17.0.6-tem. 19-zulu. 19.0.1-zulu 19.0.2-zulu. 20-tem. 20-zulu. 22.2.r17-grl. 22.3.r19-grl. 8.0.322-zulu. 8.0.362-zulu. current where current is an alias to whatever version I prefer for my JAVA_HOME (currently zipping along on 20-tem, with REPL connects in the 1-3 second timeframe… love the future! ^_^). One could certainly have their own aliases for scripting over any version, of course. I know you have quite the hand-crafted set-up, so maybe a tool like this doesn’t have as much appeal; but for myself, it’s done wonders in keeping things organized and easy for me to discover, test, and explore so much more of the ecosystem than I knew before. Their https://sdkman.io/install also mention Windows support for WSL with bash, although I haven’t had a chance to test it out myself.