[QVVRP4nYz]

> I can't think of a reason why you would want to declare something as nullable when not declaring anything automatically makes the type nullable anyway.

All existing code is "we don't know if it is nullable until someone reviews it", that is different than explicitly allowing nulls. To add to confusion all Optional<> variables should be not-null or using Optional makes no sense at all.

[jeroenhd]

Optional<> is such a weird addition to the language. I hope once this link lands, Optional<> will go the way of the dinosaur.

I use Optional<> but only to indicate at the API level that something can return null. I hope the chaining ability (?. in many languages, implemented as Optional.map()) will also one day make it to Java.

[neandrake]

I don’t even prefer it for indicating that something can return null. In most cases the Option API is more tedious and awkward than a null check and there are existing annotations that can be used to flag nullable return types, for documentation. The only places I’ve found Option to be helpful are where it helps with method composability, or in some hashmaps as a simple way to distinguish between “lookup not previously tried” vs “lookup resulted in no value” vs “lookup resulted in value” - it’s a hack and looked down upon because the Option value itself is null, but I view it the same as “Boolean” being nullable. As long as the details are encapsulated it’s not too problematic.

[usrusr]

I use Optional quite a lot, but only ever as a poor man's

   x?.let{f(it.y)}

via

   Optional.ofNullable(x).map(it->f(it.y)).orElse(null);

Will it at least get taken care of by escape analysis?

These days I'd not even trade the simple but effective approach taken by Kotlin for the full glory of Scala's Option (which is so far beyond the Java Optional).

[joncrocks]

Indeed, Optional<> was designed/intended to be used in this way.

https://stackoverflow.com/questions/26327957/should-java-8-g...

[unscaled]

Unfortunately for Java, Optional in Java is a bit of mess now, until you'll be able to specify nullability. Since T in Optional<T> has unspecified nullability, calling Optional.of() is still unsafe and can result in an NPE, if the argument is null.

What's even worse is that APIs that return Optional<T> can just return null for the Optional value itself! This a pretty evil thing to do on purpose, but this could still easily happen by mistake. If you want to make code using optionals null-safe you have to go through quite some hoops and check that both that Optional<T> is neither null nor empty.

I hope Java can now change the API of Optional and make it safer. For instance, Optional<T>.of() should require a `T!` argument, while Optional.flatMap() should require that the mapper returns a non-nullable Optional value. Likewise, linters should reject any definition of an Optional that is nullable or has unspecified nullability.

[oftenwrong]

>but this could still easily happen by mistake.

I have yet to see this ever happen, despite working in Java shops using Optional heavily since it was included in the JDK. I would guess that this is due to developers using better tooling. IDEs commonly provide warnings when returning null, or when violating a "soft" nullability assertion marked by an annotation. NullPointerExceptions seem fairly rare.

[unscaled]

I do remember seeing this happen firsthand, but I don't remember where.

Yes, this is not likely to happen with a good IDE with warnings enabled, and developers not ignoring said warnings. It is even less likely with a strict lint step in your CI/CD which treats all non-suppressed warnings as errors. This should be the standard for every software project in the world.

Unfortunately, for many enterprise scenarios, developers are not encouraged (or even discouraged) to apply these best practices. I'm talking about your typical setting with non-technical management, low-salaried or outsourced developers, tech debt rarely being fixed and the only best practices which exist date back to the 1990s or early 2000s.

Doubly unfortunate is the fact that shops of this type _overwhelmingly_ favor Java. For better or worse, Java is the #1 enterprise language and the COBOL of the 21st century. As such, something that would be a non-issue in Rust (where few developers would dare push to production code that didn't pass cargo clippy with flying colors), becomes a rather big issue in many shops.

[jonathanlydall]

While applying practices like treating warnings as errors on a CI server is something that every development team probably should be doing, it’s more a symptom of a generally weak development team than the thing that was holding the team back.

If a company policy mandated that it must be on, it would probably not meaningfully reduce poor code because the team was so poor in the first place, they probably don’t understand the problem it solves, so will just work around the now “error” using the least amount of effort to appease the CI server, while still leaving problems in their wake.

Strong teams regularly and consistently reflect on their processes towards continuously improving, such teams will naturally move to applying such a practice as it will add value.

Weak teams tend to just do what they always did until forced to do something new and even then they do it more cargo cult style than in a way that actually improves the bottom line.

[pjmlp]

All the value like types, like Optional, are planned to be value classes or value records, when Valhala lands.

[marcosdumay]

Optional<> is a problem with all languages that add nulability control as an afterthought.

If I have v = Optional<A>, if v.hasValue() does it mean v.value is not null? How does it interact with the nullability control? If v? has type Optional<A>, how do I write Optional<Optional<A>>? (And if you think that type doesn't make sense, you haven't really internalized the "parse, don't verify" rule.) If v? doesn't have type Optional<A>, why the fuck both types exist and when should I use each?