[The_Colonel]

Unfortunately these pushers were not strong enough to get Java to add null-safety. "Everything can be null" is the by far biggest daily headache of working in Java codebases.

JSR-305, checker framework, Optional are all half-baked workarounds evidenced by the lack of their adoption.

[wh0knows]

If you properly handle not returning/using nulls in your checkstyle rules and don’t allow nulls to be deserialized anywhere (forcing the use of Optional), then you can pretty much eliminate NPE.

I can’t remember the last time I encountered one by using the proper compile time checks. It does need to be enforced organization-wide, and not partially with annotations, but if you can make that change then you can code in Java without the mental overhead of null.

[chuckadams]

Does no good when interacting with the standard library, where things like collection methods return null for "not found". All that discipline and organization you're talking about? That's a compiler's job, and if it won't do so, I'll find a language that does. I don't spend much time griping about Java these days though, because I've had many such languages in my arsenal for some time now. Ironically in most of them I use null quite freely because it's now a distinct type and no longer a landmine.

[wh0knows]

Usually you’re using a lot of Optional and Streams, so the collection method returns null inside a .map() and you don’t need to think about it. To be clear, it is handled by the checkstyle rules at compile time, so you won’t accidentally forget.

[lolinder]

What about the standard library? What about other libraries that you depend on? Can't those introduce NPEs?

[wh0knows]

Inputs to standard libraries will obviously never NPE if you pass in a non-null value. For outputs, a lot of standard collection .get() calls are unnecessary when you’re working with small collections or Optionals, where you simply use stream, filter, ifPresent.

Or simply wrap the return with Optional.ofNullable, checkstyle will not accept it if you don’t.

[The_Colonel]

Yeah, if you have perfect dilligence, you can work around many language's weaknesses. But we're in an imperfect world. It's not easy to influence my coworker's code style and impossible to do with other teams or people who worked on my projects in the past and left since, yet I still have to work with their code.

> then you can pretty much eliminate NPE.

NPEs is only one kind of cost incurred by the lack of null safety. The other is all the unnecessary "if (x == null) {" boilerplate code caused by the uncertainty and defensive programming, which increases complexity and worsens readability.

[mrkeen]

> I can’t remember the last time I encountered one by using the proper compile time checks.

When you're sufficiently careful, you can reduce accidental nulls down to the level of minor inconvenience.

But no amount of care on your part will stop your teammates from deliberately using nulls.

[ivan_gammel]

Code reviews usually help to stop that.

[mrkeen]

It's too embedded in the culture.

Even IntelliJ right now will tell you off for using an Optional field instead of a nullable one.

[evacchi]

it's getting there https://openjdk.org/jeps/8316779

[The_Colonel]

> It is not a goal to support null-restricted types for identity classes or classes that do not provide a default value.

It's not. It's another half-feature into the collection of half-features mentioned in my post.