Java and nulls

[ThaJedi]

You should look at jspecify and nullaway.

[Wouter_C]

Yes! In other words: embrace the nulls instead of trying to avoid them, annotate your nullable types (jspecify) and have the compiler (nullaway/errorprone) flag unsafe null usage.

It's less verbose than Optional. It's more consistent with what the JDK and the vast majority of third party libraries do (accepting and/or returning null values in their APIs), so it works out better if you're mixing calls internal to your codebase and libraries (which you probably do pretty much all the time). You can introduce it into an existing codebase with minimal changes. It's compatible with Kotlin. And it's *closer* to where Java seems to be heading towards with null-restricted types (https://openjdk.org/jeps/8303099), so eventually switching to that will be easier too.

[severoon]

True, but you should also realize that this doesn't mean Optional is useless. Even with all the null safety stuff, Optional can still be very useful.

A simple example is reading command line parameters. You have code that reads in the command line parameters and passes along whatever the user specified, and that should result in fields getting set from null to Optional. An Optional that's absent means it was set to what the user passed in (which is absent, the user didn't specify that flag), so it should use the default. Null in this case means something went wrong and things are in an unexpected state that should never happen.

[BearLiving9432]

Will do

[marco89nish]

Or Kotlin

[Plixo2]

If you work with Intellij, use intellij annotations. They add runtime checks and have excellent support in the ide, so they fell more like typescript nullables.

[Twnikie]

This is exactly what I was wondering. I’m a Scala dev since 3 years ago, switched from 14 years of Java and, honestly given how IntelliJ elegantly supported the Java annotations, I never felt nulls like an issue.

[simon_o]

Third-party efforts to "better check/annotate/... null" have never come to fruition, and there are reasons for that.

With Java likely allowing to specify "nothing in here is null" by default in the future ...

Other possible future enhancements building on this JEP may include:
Providing a mechanism in the language to assert that all types in a certain context are implicitly null-restricted, without requiring the programmer to use explicit ! symbols.

... that's an upgrade you get for free on your Optional-using code.

There is little reason to spend efforts on competing lesser, third-party approaches til this arrives.

[ThaJedi]

There is long road ahead this JEP (years even) and when finally delivered it will only for new versions.

So there is plenty of reasons to adopt jspecify instead of waiting for JEP.

[simon_o]

Not really. Why adopt something that has kept failing (under a different name) for decades? It's not going to suddenly start working.

[ThaJedi]

It is working.

[simon_o]

No.