Yes, there is a lot of new code being written for the JVM. E.g. Kotlin is a fine choice as a language for a new backend project these days with excellent support in frameworks like Spring Boot. Also it is a drop in solution in pretty much any Java project (as in you can mix the two and they interoperate without much fuss). Modern Spring Boot is pretty nice and getting nicer with each release. In terms of feature set it pretty much runs circles around anything in the javascript ecosystem. And with a language like Kotlin it's not a bad programming experience either.
As a language Kotlin is sort of similar to typescript with a few nice features added, a bit more elegant syntax in some places, a bit richer in some places, and of course none of the madness that comes from javascript compatibility. I've seen typescript developers pick up Kotlin and liking it. Other languages it is similar to are C# and Swift. Swift is so far not used a lot for backend stuff but I could see that change. All of these can already compile to web assembly and the tooling for that is likely going to mature in the next few years to the point where you can target browsers, node.js, and native with a wide variety of languages.
I was specifically talking about Java, not the JVM in general. The latter is obviously still a great technology and it hosts some of the best up and coming languages.
You cannot meaningfully differentiate between Java and the JVM because all popular JVM languages (Skala, Clojure, Kotlin, Jython) can interact with Java libraries. In fact, they are even using this to market themselves.
Java libraries are the way to program for the JVM and all its (popular) languages.
I've work for large national ISP where they are heavily trying to create a new series of network engineering tools (device discovery, adding new ARs with ease, upgrading existing devices, pragmatically change thru-puts between regions based on load, etc).
Most of the backends for these types of tools would explicitly be done in Java. Why did they chose Java? Mostly because they would staff entire teams with H1Bs and dump them after 5 years. The directors of these projects would only hear about "buzzwords" surrounding the latest tech if they themselves went to conferences or happened to luck out if the project managers they hired had varied experience.
Oddly enough, there's a lot of greenfield work being done using Scala at Verizon and Comcast. But from my direct experience, it's entirely dependent on the team. The more the team doesn't rely on contractors the more likely they are to use niche tech.
If your systems are Java, you'll hire people who can work in Java, and if the only thing your devs have in common is experience with Java, your new code will be in Java too.
I guess "great test tooling" and "broad library support" are subjective, but there are several contenders these days that I would say might fit those criteria
>>there are several contenders these days that I would say might fit those criteria
Even if you get the basic 'Batteries Included' part right, you still won't match up ubiquity in terms of being able to hire developers(in big numbers), common knowledge base, maintainability of code bases. Java code bases tend to be around for long. And people of all skill levels can get started with minimal handholding.
Also note not all companies have the revenue streams of top internet companies. And they can't afford to flush hundreds of millions of dollars, and man years of personnel time down the sewers to arrive at hiring the perfect candidate for the job. Almost always most companies need candidates who can get job done, for whatever salary they can offer. And they can't afford to rewrite their code every two years, so they care deeply about things like easy hiring, and code maintainability on the longer run.
Apart from these things Java itself is a great piece of tech, and has passed the test of time over so many technology trends.
If you are starting a backend project, Java is more or less the best and the top tech choice at this point, and has been for long now.
> "great test tooling" and "broad library support" are subjective
Not really the case when it comes to Java (and the JVM in general). It objectively has great test tooling, and a very diverse library ecosystem, not to mention monitoring, introspection, management, tunability, etc. are second to none. The only other ecosystem that arguably comes close is .NET.
I can only speak from experience, but I know two large corporate entities that used Java and have over the years dropped it in favor of Go and websites.
Edit: i like how my first hand experience is disagreeable and should be hidden. This site gets STRANGE with facts that users just don’t want to see.
The issue is I can’t change my first hand anecdote of the two companies specifically I’ve been to having switched to Go and web apps from their older Java applications.
