> Thank god for that, because those feature are either horrible on their own or superseded by better ones.
Are they though? I agree mutable data classes and property _setters_ are bad, but what about the rest?
I personally like the idea of checked exceptions, but there is no doubt they failed to deliver on Java. Perhaps the good parts of this idea can be salvaged by having an easy way to explicitly wrap a checked exception, like with_context() in the anyhow Rust crate. Kotlin dumped checked exceptions in favor of Results, and I don't see how Java has anything right now that supersedes that.
Explicit nullability is unarguably a good feature. You could make a convincing argument that expressing it with an Option/Maybe is better than the road that Kotlin, Swift, C# and TypeScript took. But Java's Optional is not that solution, since the T within the Optional can still be null. And I'm not even getting into how verbose and unnatural using it feels, or the small issue of having to rewrite all the existing Java APIs to make it work.
The same goes for having eager collection operators. The JIT compiler might be able to inline and optimize simple stream operators, but the ergonomics of doing simple things on a collection is just bad.
But even if Java does all of that, just lack of extension methods and top-level functions make using Java a nightmare for me. If Java had extensions methods (or an equivalent concept like Type classes or the Uniform Function Call Syntax that D has), the previous complaint about lacking collection operators directly defined on Collection and Iterable will be a non-issue. Just let anybody who wants it define their own.