In fact, the officially supported Java releases for Clojure are all LTS releases. This is also reflected in their CI. At the moment, that means 1.8, 11, 17, and 21.
I would also like to mention, for non-Clojure users: it took ages for Clojure to finally get off Java 1.5. The compiler was still emitting 1.5 compatible bytecode as late as 2018. Since the release of Clojure 1.10 (17 December 2018), the minimum Java version was bumped up to 1.8, in the sense that the compiler now emits 1.8-compatible bytecode.
There is a strong emphasis on moving slowly and NOT breaking things in the Clojure community. Likewise, if you look at the most recent Clojure survey results, the vast majority of people were still on 1.8 and 11 releases.[1]
I actually do feel like this is partly what's responsible for Clojure's relative success in industry. If you have a company with a ton of Java 5 code, and you want some of the sexy functional programming features, your options basically boil down to "upgrade everything to the newer Java 8 to get maps and optionals and whatnot" or "just write this new service in Clojure that will happily interop with our Java 5 code".
I'm not making a judgement on which decision is better, but I can totally see the appeal, at least in the short term, for people choosing Clojure, especially if they think that Clojure's API will be largely unchanged in the Java 8 update. It doesn't hurt that Clojure is just broadly a really pleasant to work with, at least in my opinion.
> If you have a company with a ton of Java 5 code...
You are in deep deep trouble already, just process-wise. If you're making money hand over fist you might be able to afford to do that, but choice of language is not even on the radar in terms of what needs fixing.
Now, if you mean in terms of digging out of that hole... just upgrade to newer dependencies, newer JDK versions, etc. That's the way to better performance, better memory usage, better GC, better everything... and THEN think about the language you're using.
> You are in deep deep trouble already, just process-wise.
Code is usually a much smaller piece of company's business process than we developers like to think.
> If you're making money hand over fist you might be able to afford to do that
Here's the problem though: the vast majority of companies on the planet don't "make money hand over fist", they just have small to reasonable profit margins. And most businesses can't just risk losing what's already been working for a decade just because some developers want a new shiny thing every six months.
That's the reality which JVM and Clojure folks take very seriously, but is very often overlooked by younger people.
> Code is usually a much smaller piece of company's business process than we developers like to think.
I agree.
Btw, I think you inverted the meaning of my sentence regarding 'hand over fist'. I was saying that staying on an old version is asking for trouble and is going to cost a lot more than upgrading.
> That's the reality which JVM and Clojure folks take very seriously, but is very often overlooked by younger people.
Ah, the irony of being called young because of a comment I made :). I'm an old hand at this point.
FWIW, my shop also stayed on JDK 8 for a bit longer than we should have, but that was largely because of upstream dependencies. We're currently on JDK11, but again just because there are some upstream dependencies that are holding us back from JDK17. (It's mostly to do with the infamous module system change. It's a good change overall, but some projects have been super-slow to adapt.)
These are very good points. The programming language used is a tiny sliver of the pie chart required to run a profitable company. The entire “technology” portion of that pie chart is still only around 20% (at best) of a profitable company.
I would also like to mention, for non-Clojure users: it took ages for Clojure to finally get off Java 1.5. The compiler was still emitting 1.5 compatible bytecode as late as 2018. Since the release of Clojure 1.10 (17 December 2018), the minimum Java version was bumped up to 1.8, in the sense that the compiler now emits 1.8-compatible bytecode.
There is a strong emphasis on moving slowly and NOT breaking things in the Clojure community. Likewise, if you look at the most recent Clojure survey results, the vast majority of people were still on 1.8 and 11 releases.[1]
[1] See Q24 in https://www.surveymonkey.com/stories/SM-_2BH3b49f_2FXEkUlrb_...