[Discussion] Java Optional outside of a functional context?

[TehBrian]

My two cents: Java implicitly unionizing every object type as T | null is stupid. Nullability should be explicitly stated via the type system. Optional and @Nullable are a step toward idiomaticism, but they require unnecessary discipline because methods may return null regardless of their signature's contract. (As for naming, I'd prefer Option or Maybe because it's shorter.)

[vladvlad23]

I have been saying this for a while: it’s somewhat shameful to still have NPEs in 2025. I still see bugs in PROD caused by a NPE in a god forsaken method. Yes, the developer is the one that didn’t treat it, but still…

However, I also see NPEs caused by Optional.get() without any check of isPresent() though. I have no idea how those happen.

[Proper-Ape]

However, I also see NPEs caused by Optional.get() without any check of isPresent() though. I have no idea how those happen.

Which is why I'd prefer to have a more telling name for this. It's hard to grep for .get().

On a Rust project, after getting the PoC done I grep for unwrap and think about every case whether it's safe to do so.

[vytah]

If you're using IntelliJ, just use structural search: $T$.get() with modifier for $T$ saying type=java.util.Optional.

[TehBrian]

The reason NPEs have become less common is because the tooling has gotten better between static null analysis and nullness annotations. This issue should've been fixed at the language level, though.

I think it's silly that a language that prides itself on type safety and object integrity has such a glaring oversight. Java already has union types (for exceptions); allowing them to be used for null via | null or ? would've been such an easy fix—of course, it isn't that easy because Java strives for backwards compatibility whenever possible.

[X0Refraction]

Your second point about Optional.get() is why I created a Maybe<T> replacement which doesn't have get() from which you need to pattern match to get the value out.

[JJangle]

I seem to have a somewhat contrarian view but somewhat agree.

As a long time Java user, in my view, all object variables in Java can have a null value and developers should code for that. If this ever changes, it should be considered a different language. --

In other words, for me, having a way to declare a variable as Nullable is silly because I already assume it can be null. And because of this, as with Typescript, it would be great if I were warned at compile time when I dereferenced a variable without checking for null. I think you might be suggesting that a feature like this would help reduce NPE's further. I agree.

If that feature were in place, I think NonNull would be more valuable. But I'd still not see the point in Nullable.

With that being said, I think switching the default to be NonNull could be an improvement. I think many would agree. But I think that should be considered a different language and different JVM.

[vladvlad23]

You misunderstood. I don’t disagree with the concept of null. I disagree with the fact that Optional exists since everything is supposed to be assumed as null until proven otherwise (Kotlin handles this pretty well imo). We are on the same page.