But it sounds like your problem isn't Java/JVM, but rather really shitty code. If it breaks when you change minor versions of the JVM, the code is broken.
Just from my own personal experience, you've just indicted code from three well-known SV companies, at least two more non-SV fortune-500s, a mess of B2B vendors, the Apache foundation, and a few minor, independent open-source projects. I've heard stories from friends in a few other companies about both internal and third-party code.
At some point you reach the conclusion that the problem with an ecosystem is more fundamental than a few lazy developers. But even if not, your statement isn't actionable. If all the code in a certain set happens to be really shitty, the only rational choice is to not use that code. Any other argument ends up being one only of semantics.
You'll have all seen the pattern. The sort of people who use language X tend to be the same people who use VCS Y tend to be the same people who think doing Z is a good idea tend to be the same people who don't see any problem with IDE W and protocol V.
Culture (by definition) is something that propagates amongst a community, and sometimes it's just poisonous. Or at least seems poisonous from an outsider's point of view. Except if it's java, in which case there's no two ways about it.
I think I've deployed only one java web app (puppet-db) that doesn't have huge memory leak issues. With the lack of process recycling in tomcat to mitigate "bad code", I cringe every time I have to deploy another one.
At some point you reach the conclusion that the problem with an ecosystem is more fundamental than a few lazy developers. But even if not, your statement isn't actionable. If all the code in a certain set happens to be really shitty, the only rational choice is to not use that code. Any other argument ends up being one only of semantics.