The design of Java is focused on code maintenance. That's exactly what young developers lack experience in. They know how to write greenfield code, by themselves. They haven't yet looked back at code they wrote and said, "ugh, what the hell was I thinking?"
Since Java was developed the world has shifted to accommodate a lot more rapid development and code you throw away rather than maintain. But experienced developers also know how often "prototypes" are still around decades later.
Java is also not perfect, and a lot of new languages are conscious of its faults. But the reason it's still around is that it's core principles are oriented to code that sticks around.
> But the reason it's still around is that it's core principles are oriented to code that sticks around.
You could equally say this of COBOL.
> They haven't yet looked back at code they wrote and said, "ugh, what the hell was I thinking?"
Ironically, "what they hell were they thinking" is exactly the reaction I have to even Greenfield code written using Spring Boot or any of the other annotation driven nonsense.
The idea that programs written in Java are more maintainable than programs written in (say) Go, where you can read what the program does end-to-end instead of having to guess at what garbage has been generated by Lombok or overridden by some random JAR on the class path is bizarre. Let's not even talk about Gradle.
Yeah, I'll defend Java, but I won't defend Spring. I have no idea what they were thinking.
A lot of external Java framework is about inversion of control. It looks good on PowerPoint slides, but I think it's horrific to maintain (as well has hard to write). Inversion of control means you have no control, and the most common error case is "why didn't my code run?" But you can't use a debugger to tell you what didn't happen. Any breakpoints have to be set inside the framework code, which is open source but is not intended for your eyes.
I have (in depth, often under the gun of a production outage).
Kubernetes is not a good example of idiomatic Go in any sense. Perhaps Spring Boot and friends are also not good examples of idiomatic Java, but they are absolutely the common case of what is found in the wild.
Kubernetes is a single (bad) Go project. Every piece of Java I ever see is AbstractFactoryProxyBean nonsense with annotations all over the show.
I don’t know of a Go project where I can’t start at main (for a given program) and work out how it works without a bunch of ecosystem context. I can’t think of a single Java program where I can.
I have experience with code maintenance. The only upside of Java is that it's faster than JS or Python. It's otherwise a worse language and ecosystem, and it was even worse before it had lambdas.
My problems with Java are startup time and memory consumption (and NPEs).
If that's not your problem - fine. But writing web apps in the Java ecosystem has been terrible for many of the most important years (let's say 2005 to 2015) and that's where all the "young people" forsake it for... PHP, Rails, node.js.
(You can already guess that I'm not even counting myself as part of the younger generation here. I'd used used Java and the JVM intermittently between 2000 and 2020 but it has never been my favourite stack).
Java was so bad that Android took a hard pivot to Kotlin. If anyone understands the importance of code maintenance, it's Google. They built a language for it (Go). I think it's ok to look at historical Java for what it is and learn from it's mistakes. Modern Java is better. Unfortunately, it's developed a bad rap, and it looks like it's in a decline. Fortunately we have Kotlin, Go, Typescript, etc.
Since Java was developed the world has shifted to accommodate a lot more rapid development and code you throw away rather than maintain. But experienced developers also know how often "prototypes" are still around decades later.
Java is also not perfect, and a lot of new languages are conscious of its faults. But the reason it's still around is that it's core principles are oriented to code that sticks around.