7 ms·

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

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.

lolinder 2y ago
What about the standard library? What about other libraries that you depend on? Can't those introduce NPEs?
- wh0knows 2y ago
  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.
mrkeen 2y ago
> 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 2y ago
  Code reviews usually help to stop that.
  - mrkeen 2y ago
    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.
chuckadams 2y ago
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 2y ago
  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.
The_Colonel 2y ago
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.

lolinder 2y ago

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

wh0knows 2y ago
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.

mrkeen 2y ago

> 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 2y ago
Code reviews usually help to stop that.
- mrkeen 2y ago
  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.

chuckadams 2y ago

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 2y ago
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.

The_Colonel 2y ago

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.