Best JDK version for new Clojure environment

I’ve just acquired a new Mac and was in the process of setting up a completely fresh environment on it (didn’t do a backup/restore of previous data). I installed brew and was looking at all the AdoptOpenJDK options available. My previous environment was running Java 8 and I didn’t ever have a need to upgrade it thus far, but this new machine is forcing me to make a decision. So, what’s the “best” Java version for Clojure at this point? Is it completely a “don’t care” since Clojure 1.10 just targets Java 8, or are there stability, performance, or other advantages to, say, Java 11+?


1 Like

I have some instructions I started writing up, which include how to install multiple JDK versions on a Linux or macOS system, and switch between them easily, that is pretty much common between those two operating systems (i.e. there isn’t really anything macOS-specific about it).
They are not complete for my original purposes I started writing them, but should be complete for the JDK install part.

Just about any JDK version 8 or 11 are the most recommended right now, since both are widely used, and both under long term support from Oracle and multiple OpenJDK distributors.

If you want to use Cognitect’s REBL, I have had success on macOS using Zulu OpenJDK 8 and 11 if you get the “JDK FX” versions that include OpenJFX libraries bundled with them, and those work for both Linux and macOS for that purpose.

1 Like

Thanks Andy. Are you seeing a big difference between the Azul runtime and the AdoptOpenJDK runtime in terms of performance? I know that Azul has a generally-better GC capability. Generally, for the programs I’m writing, I’m not stressing the GC to the max.

I have not done performance tests between JDKs any time recently.

I use Zulu JDK 8, since it bundles JavaFx with it.

The performance between all JDK of the same version will be equal. Zulu doesn’t contain a different GC. I think you’re thinking of their paid JDK.

Their webpage is actually pretty good on comparing the different JDK:

I think that if you go with JDK 9+,like 11 or 13, there are more shenanigans to get some things working sometimes with the new modules. You could have some older library for example that doesn’t work with it.

For performance, I think unless you plan to experiment with the new experimental GCs it won’t matter much.

My recommendation: JDK 8 that is available with your package manager, if that’s AdoptOpenJDK go with that. And Zulu if you need OpenFX.

1 Like

The only thing that comes to mind is there is a potential performance difference if you run your app in public cloud/containers. With JDK8 you need to set some experimental heap/memory flags manually:

-XX:+UnlockExperimentalVMOptions -XX:+UseCGroupMemoryLimitForHeap

With JDK10+ they are enabled by default:

I guess it just means you get better performance out of the box with less configuration, as these flags are still available on JDK8 you just need to remember to turn them on. :sweat_smile:

Thanks for the info, folks. I settled on AdoptOpenJDK 11 since it’s LTS and has got support for Brew. I’ll try that, @didibus, and if I run into any problems, per your comments, I’ll switch back to Java 8. Right now, I don’t need JavaFx, and Zulu is a bit more trouble to install and manage long term (brew upgrade is really nice). Maybe I’ll try it down the road.

Tip: try jEnv for switching between JDK versions. I use it on macOS.

Is jenv literally a software package that sets the one JAVA_HOME env variable for you, and/or adds a directory to your PATH, and that is it? It is a 2-line bash script.

It does a little more than that. You can register multiple JVMs with it so you can switch between them by name. It supports setting a JVM version per directory (project), only temporary for a shell or system wide.

1 Like

Tip: try jEnv for switching between JDK versions. I use it on macOS.

That’s probably overkill for what I need right now, but it looks interesting. Definitely helpful if you have to manage an environment with multiple JDKs for whatever reason (e.g., working on old releases of code, etc.).

1 Like


I am glad you opted for AdoptOpenJDK. For what its worth, merely the effort of what this project constitute deserve attention - the project fills an important gap in the JVM echosystem.

Regards, Henning

1 Like

I use for this purpose (per-dir PATH and other variables) and the OSX java_home - v 1.8|11 executable. I’m looking forward to trying (with direnv). Better than per language solutions

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.