Have you ever had to maintain an old enterprisey Java thing? It's pure hell.
Basic dependencies (like JUnit) break API compatibility every few years, and then they stop distributing the old version for new JVMs, so you're forced to port your code. The GC falls over in production at the least convenient times. People somehow decide everything should be stringly-typed, and that the best choice between .properties, xml and JSON is "all of the above, and also this in-house DSL". There's this common pattern called "vendoring" where you load multiple incompatible versions of the same library into the same JVM, and exploit loopholes in classloader semantics to prevent it from noticing, and ungracefully exiting (which is what it really, really should do).
There's no way to use language improvements and static analysis to improve program semantics over time (like there is in, say C++) because none of the language level abstractions are sound.
For example, you have a line like "static Foo foo = new Foo()". Guess what? foo can be null sometimes. Here's an unrelated problem: Think you have a function that doesn't throw exceptions? Nope. Some third party garbage can throw errors during normal operation instead. Think that eliminating down casts in your program means it won't throw ClassCastException on unexpected lines? That hasn't been true since generics were invented. Think Optional gets rid of null pointer exceptions? Nope. Instead, it's actually a tri-value null. After all, you can always create null references to an Optional (and, looping back to the beginning of the paragraph, you can't avoid creating null references to Optionals in idiomatic code!)
> Have you ever had to maintain an old enterprisey thing? It's pure hell.
FTFY. And yes, I have worked on old Java apps, they are not worse than any other app that lived for a similarly long timeframe (and the fact that there seem to be more old monstrosity in Java may just mean that it actually manages to do its work written in java, and not fail in some other language).
Why don’t you have a bin repo for old junit versions? Nonetheless, not updating is just technical debt that will have to be paid once either way. Regarding GC, it was never as bad as its name in my opinion, but it improved dramatically in recent years. If it fails it is more than likely a programmer error (which is very easy to debug thanks to the JVM’s killer observability).
Regarding XML and .properties, this is related to enterprisyness not java, nor the JVM. These are meaningful abstractions to a degree but are overdone badly more often than not. Vendoring is not really a hack, it is a correct choice from the JVM’s PoV (in short, a canonical name and a classloader pair is unique inside the JVM), but it can be abused, and application servers kind of do so indeed.
Wtf, Java has probably the best tools when it comes to static analysis. It actually has a well-defined specification of what has to happen under nigh every circumstance, and Java is huge in academy as well so different kind of analysis is an active research topic, especially that Java is also huge in the industry.
Runtime exceptions are a thing everywhere, I again fail to see how are they relevant here, and Java is completely type safe with generics, your statement regarding that is completely false. If you don’t have casts in your program, it can’t fail with classcastexception (reflection-hackery aside).
Optionals are a mistake but the only fault lies in those who put a null inside.
> Optionals are a mistake but the only fault lies in those who put a null inside.
If you, or a third-party exposed a "Optional", then it's the API mistake. You're never supposed to expose an Optional as either input or output; they're clunky implementation details of the Java Maybe monad.
Basic dependencies (like JUnit) break API compatibility every few years, and then they stop distributing the old version for new JVMs, so you're forced to port your code. The GC falls over in production at the least convenient times. People somehow decide everything should be stringly-typed, and that the best choice between .properties, xml and JSON is "all of the above, and also this in-house DSL". There's this common pattern called "vendoring" where you load multiple incompatible versions of the same library into the same JVM, and exploit loopholes in classloader semantics to prevent it from noticing, and ungracefully exiting (which is what it really, really should do).
There's no way to use language improvements and static analysis to improve program semantics over time (like there is in, say C++) because none of the language level abstractions are sound.
For example, you have a line like "static Foo foo = new Foo()". Guess what? foo can be null sometimes. Here's an unrelated problem: Think you have a function that doesn't throw exceptions? Nope. Some third party garbage can throw errors during normal operation instead. Think that eliminating down casts in your program means it won't throw ClassCastException on unexpected lines? That hasn't been true since generics were invented. Think Optional gets rid of null pointer exceptions? Nope. Instead, it's actually a tri-value null. After all, you can always create null references to an Optional (and, looping back to the beginning of the paragraph, you can't avoid creating null references to Optionals in idiomatic code!)
I could go on for hours.