At least from an Android point of view, the JVM world still has its share of frustrations and lack of polish/QoL relative to other software development spheres. Gradle has me pulling my hair out multiple times each year for example, and yet for some reason nobody sees it fit to replace it with something less ridiculously complex and prone to error (user or otherwise).
Don't blame Java for the misteps of Google and Android team.
Android started being devleoped mostly by C++ refugees, that is why originally all framework code is full of m_ prefixes.
Then the whole standard library fragmentation that persists to this day.
Despite the whole excuse why Dalvik was created, Nokia and Sony-Ericson had quite good JVM implentations for Symbian.
When Kotlin was introduced they stiffled Java on purpose, left it on Java 8, using Java 8 examples to promote Kotlin, and have since Android 12, started to finally update ART to more modern versions, because as it turns out, even with Kotlin, loosing compatibility with the Maven Central ecossytem isn't that great.
Still, it is mostly Java 17, and all the ongoing improvement in Java land across all JVM vendors, will most likely never land on Android.
Android is not Java, even though it relies heavily on the ecosystem for its tooling.
Android is basically Google's .NET, and Kotlin plays the same role as C# in relation to Microsoft's J++, that lead to Sun's lawsuit.
Jetbrains have a project to try and replace Gradle.
I've looked at it also. The problem is incentives. Will developers pay for a better build system? Probably not. Then, what people use is whatever happened to be given away for free first.
Another problem with shifting Gradle is that lots of libraries now come with build system plugins too, so you'd need to replicate all that logic into whatever new build system you create. And it's actually not easy to get everyone to agree on what they don't like about Gradle. Say "imperative not declarative" and half of devs will agree and the other half will say, no, you need programmatic configuration because build systems are genuinely complex. Etc.
I've long since given up on Gradle being able to get this stuff right. The syntax they're proposing is the THIRD similar-but-incompatible syntax they've adopted after Groovy and Kotlin. Good luck figuring out which is in use by looking at a code sample.
The biggest problem with Gradle is not Kotlin or even Groovy syntax. Kotlin isn't a bad language to use even for writing configuration. It's that the entire thing is designed in extremely confusing ways from back to front, and has a lot of awkward design choices and bugs that result in a hyper-complex user model.
What the JVM world needs is a totally new tool that has the same feature set as Gradle but with a drastically simpler mental model behind it. The only real contender right now is Bazel, I think.
Yeah, gradle/maven was a mistake that happened along with most "app store" style 3d party library slingers.
I'm of the opinion that the world was a better place with Ant and when we had third party dependencies manually, deliberately adn deliberatively managed by hand in /jars/thirdparty
