Optional<T> is itself a reference and can itself be null. That effectively torpedos the entire concept out of the gate. Nullity being part of the data type is a huge difference, and exposes so many "I didn't know that could be null" spaces.
I've seen both Optional<?> return null (inexperienced dev) and somebody arguing we should defensively check for null Optionals as well (experienced dev).
What you're arguing is a false equivalence. In practice null safety isn't a problem when developing in Kotlin while it is a big problem in Java.
PMD itself is no standard though. Best standards are enforced in compiler anyway.
> Not everything needs getters and setters, it is just cargo cult generating them blindly.
JavaBean spec (with getters and setters) is actual standard. It's purely theoretical argument that you don't have to use them while in reality they are used always and everywhere and any PR without them would be shot down immediately.
Setters/getters are just one example of Java's boilerplateness.
> Static analysis like PMD is also a basic need, not using something like Sonar as part of a CI/CD is just being careless.
Yes, but I want that feedback during coding and not in CI/CD. Yeah, I can set it up in IDE, but that's more configuration, more things to break up, more team wide standards. Why not just use Kotlin?
I'm no Java hater, I code Java for most of the day professionally. But why pretend that it's perfect? It's 25 years old with unfixable mistakes built in and ripe for replacement.
> JavaBean spec (with getters and setters) is actual standard. It's purely theoretical argument that you don't have to use them while in reality they are used always and everywhere and any PR without them would be shot down immediately.
Sounds like a strict "your company" problem. No one needs to use the JavaBeans spec. It's fully optional.
> Yes, but I want that feedback during coding and not in CI/CD. Yeah, I can set it up in IDE, but that's more configuration, more things to break up, more team wide standards. Why not just use Kotlin?
You make a very weak case here for Kotlin since you need a static analyzer anyway (e.g. Detekt).
> I'm no Java hater, I code Java for most of the day professionally. But why pretend that it's perfect? It's 25 years old with unfixable mistakes built in and ripe for replacement.
No one pretends Java is perfect. For many projects I like using Kotlin. But there's also substantial investment in Java and "I have to type a bit less" is usually not enough to justify using Kotlin.
> Sounds like a strict "your company" problem. No one needs to use the JavaBeans spec. It's fully optional.
Your company - maybe I've been working in the wrong companies in the past 15 years, because Java's setters and getters have been used everywhere. Also look into some open source projects - how often do you see direct access to (non-final, non-package private) instance variables? Can't really recall a single case. For a good reason - exposing field access on a public interface violates encapsulation.
> You make a very weak case here for Kotlin since you need a static analyzer anyway (e.g. Detekt).
Of course static analyzer is necessary. That does not invalidate the claim that null safety guaranteed by a compiler is much faster/more effective.
> "I have to type a bit less" is usually not enough to justify using Kotlin.
Type less is a small price in typical large scale project. The big win is better readability since you don't have to scroll over tons of boilerplate or artificial abstractions caused by Java's rigidness.
Besides that NPEs are still happening in production all over the world so something is obviously "not ideal".
And when they become available, Java will have them on day one, while Kotlin who knows, specially when it needs to stay compatible with ART.
Kotlin designers will have eventually to face the reality that they are either an Android only language, or that Kotlin multi-platform will need to differentiate between what is supported on JVM and ART.
