> because it took so long to identify and respond to these moves by competitors
This is and has been Java's explicit strategy since the Gosling days. They watch and wait and implement changes at a glacial pace. They let other languages figure out what works, and implement changes only after they've been demonstrated useful and caveats and pitfalls have been thoroughly explored.
This conservative and deliberate change process permits much better backward compatibility and a level of stability that is very rare among programming languages.
When Java was new it was pretty radical though. At least in the category of mainstream corporate languages. Who else was offering things like an advanced speculating VM, stable/documented bytecode, a huge stdlib, a cleaned up C++ like memory safe language with reflection, sandboxing, applets etc? It was sufficiently radical that MS had nothing like it and felt a need to respond with their own Java impl and later .NET, the UNIX world had nothing like it either and that led Miguel to try and implement .NET for GNOME.
If you compare Java to obscure languages that hardly anyone used outside of the MIT AI Lab then you could argue it was conservative. But that wasn't the space it was playing in.
It feels like this Java as slow-follower idea is actually relatively "new" and more of a response to it slipping from being a relatively futuristic platform in the 1990s to being unable/unwilling to really try new things now.
Java was always conservative on the language front, but much more experimental/state-of-the-art on the runtime one, and that is still true today (e.g. GC-wise no other language is even close to Java’s, and basically every research is against that)
The other way to see this is that a powerful runtime allows to write more straight-forward code.
Allocation in the heap allows for much more powerful programming constructs as n object owns it’s own memory layout. Back in 1990 the cost of pointer indirection was virtually free. The need for stack allocation came up only somewhat recently. And the value object model Oracle has come up is infinitely more powerful than what comparable languages are offering.
The trend in performance is allocating more jobs to the runtime. In HPC, this is already the de-facto standard.
Having to break less due to regenerative breaking in electric cars doesn’t make advancements in breaking technology obsolete - surely, java will get to value types sooner or later that will decrease the amount of allocations, but most programs do make extensive use of the GC fundamentally, so both advancements will improve the language.
This isn't particularly relevant. Java has been very conservative with language changes since at least 8 (2014) but I'd argue 5 (2004) so for the past decade or 2 it has been a conservative language.
I wouldn't want to work in an ever evolving always experimental language. Languages that keep changing are annoying and makes your code break. That's time and effort spent not building stuff.
This is and has been Java's explicit strategy since the Gosling days. They watch and wait and implement changes at a glacial pace. They let other languages figure out what works, and implement changes only after they've been demonstrated useful and caveats and pitfalls have been thoroughly explored.
This conservative and deliberate change process permits much better backward compatibility and a level of stability that is very rare among programming languages.