or maybe if emacs was calling clj from inside the project context something else would set the version of java?

JAVA_CMD environment variable + something like dotenv.

this is considered to be external to clj

better to set JAVA_HOME (JAVA_CMD is kind of last resort)

clj just uses whatever java is on the command line OR java as set at JAVA_HOME OR whatever is in JAVA_CMD

Ah, of course. Actually, where did JAVA_CMD come from? Compatibility with some existing tools? Not easy to find online.

didn't come from anywhere

I think maybe lein uses that too ?

it's not a standard thing or anything (like JAVA_HOME is)

If you are using sdkman you might want to have a look at its https://sdkman.io/usage#env

We use https://www.jenv.be/ to manage versions of the Java runtime. I would not expect Clojure CLI or Leiningen to care about and certainly not manage the version of it's underlying host. The only reason I've needed to use a tool to manage Java versions is for bugs in driver libraries (usually the more niche libraries) or really old projects with less maintained libraries that are not worth investing time to make better

I think i understand. I'll need to set my version of java when ever i enter the project, possibly using JAVA_HOME. @U05254DQM i used jenv to set the local java version in the project, but when emacs starts a repl via cider-jack-in, it seems to sue the global version of java. Maybe i just need to give up on having emacs start the Nrepl, it was nice because then it could keep the nrepl client and server in sync, but i guess i could just use the RELEASE version in my project deps?

though maybe i'm not setting JAVA_HOME... let me check 👀. it seems like i am setting it with something like java_home.

actually maybe the practical solution is to just update java 🚀

Updating to the latest LTS version of Java (17) means you can forget about Java versions for a few years for the majority of Clojure projects. I wouldn't set JAVA_HOME anywhere, it probably interferes with the jenv tool (and similar tools). There aren't many guarantees that environment variable would be used. Unless an OS path or environment variable related to the Java excecutable location is specifically set in Emacs e.g .spacemacs.env then Cider jack-in should use the same Java version as running Clojure or lein on the command line. Cider jack-in creates the Clojure or lein command and runs it in the context of the current project.

To use Cider connect, I run a repl process using one of the alias from my https://github.com/practicalli/clojure-deps-edn user level config, which I can then use for all projects and minimises any version maintenance. I have a few variations, e.g :repl/rebel to run a rich ui in the terminal along with the repl process and nrepl or :repl/headless to run a a repl process and nrepl without a cli I also have aliases to do hotloading and reloading namespaces that I can add to the mix when needed.

That's a good point, i didn't check spacemacs.env. i could have Java home set there, which could be leading to my confusion. Thanks a lot for the help.

@U0DJ4T5U1 If you're looking for a more general solution, I recommend stopping by in #nix. With it, you gain a way of reliably declaring external dependencies like Java or the Clojure CLI (basically like jenv but for any package). Combined with direnv and emacs-direnv this even works transparently with cider-jack-in.

However, it comes with a bit of a steep learning curve 🙂

At least once you want to move beyond these basic features

(or sdkman jabba asdf-java) w/ direnv is magical

Now, how do i switch between my package managers?

If you invest in learning Nix, you pretty much won't have to anymore 😄 As mentioned above, it's not specific to any one language ecosystem but a general solution for declaratively managing packages both on the system and on the project level.