The reason is obviously Java 9 which broke compatibility in many areas <a href="https://www.oracle.com/java/technologies/javase/9-relnotes.html#JSERN9" rel="nofollow noreferrer">https://www.oracle.com/java/technologies/javase/9-relnotes.h...</a>
You use a Mac.<p>You search for java.<p>You click the first result and go to java.com.<p>You click Download Java.<p>You are given Java 8.<p>You are now somehow a mystery.
.Net has the same problem[0] 45% still "regularly use" .Net Framework because, like Java 8, .Net Core broke compatibility and even in spite of Microsoft's efforts to offer upgrade routes, it is still a hugely painful experience. Particularly for those stuck on libraries like Asp.Net.<p>Their current best solution is to put a modern version wrapper around .Net Framework and to map between them, but that isn't exactly ideal either (since you wind up with a giant mess).<p>[0] <a href="https://www.jetbrains.com/lp/devecosystem-2023/csharp/" rel="nofollow noreferrer">https://www.jetbrains.com/lp/devecosystem-2023/csharp/</a>
I feel for Java. Everytime I've used it, I've been pleasantly surprised by the language. It has some truly amazing features (steams where very cool).<p>Then I get to the tooling and it's just such a pain, if it's working we don't touch it. Our repository was checked in "eclipse format". Tried to move it to jetbrains. No dice. it too, me a few days to get it so i could compile and run under eclipse. I'm not an expert but I don't want to touch it for fear of breaking. New projects aren't done in Java. Php perl and python have a better dependency story, though slower.
Concur.<p>Another data point. Our open source JWT library[0] and Java client library[1] both target Java 8 because that is widely used.<p>0: <a href="https://github.com/FusionAuth/fusionauth-jwt">https://github.com/FusionAuth/fusionauth-jwt</a><p>1: <a href="https://github.com/FusionAuth/fusionauth-java-client">https://github.com/FusionAuth/fusionauth-java-client</a>
For context on possible sampling error:<p><pre><code> - 50% use Java 8
- 72% use Spring
- 74T use Maven
- 78% use IntelliJ
- 38% develop web site
</code></pre>
If it works, don't touch it.
Java 8 (maybe 9) is the last version I wrote code for. Having looked at recent new Java features it looks like a completely different language now. I also see a lot less new projects written in Java, at least in the OSS sphere. Just anecdotal.
Ninite.com lists the following Java installs:<p><pre><code> 64-bit Java Runtime (JRE) 8u392-b08
32-bit Java Runtime (JRE) 8u392-b08
64-bit Java Runtime (JRE) 11.0.21
64-bit Java Runtime (JRE) 17.0.9
64-bit Java Runtime (JRE) 21.0.1
</code></pre>
How is the average person to know which one is best for them and why?
The ASF world is finally moving forward. Java 11 is pretty much ubiquitous, and I'd expect latest LTS versions to be supported by default going forward.
The Java I encountered at work didn't even use Java 8's features. People balked when I suggested using vavr to get some functional programming goodness.<p>The culture around Java is conservative; it has a lot of inertia. That's why I support Kotlin; it forces project contributors to leave their dated habits behind. Java libraries still work, of course.
This is unfortunate considering how far the language has come since then. Local variable type inference (i.e. the `var` keyword) is very difficult to give up once you’ve gotten used to this being table-stakes in basically every other modern statically typed language.