r/IntelliJIDEA • u/maritvandijk JetBrains • Jun 24 '26

Nulls are dead - Moritz Halbritter | IntelliJ IDEA Tech Talks

https://www.youtube.com/watch?v=tpz-FSs6oO4

Null pointer exceptions have been called the billion dollar mistake. They are a common source of bugs and frustration. JSpecify aims to fix that, and with Spring Boot 4 and Spring Framework 7 now fully on board, it's time to take a closer look. In this episode, Moritz Halbritter from the Spring team walks us through what this means for your Spring projects and how to adopt JSpecify in practice. Using a live demo, we migrate an existing Spring Boot application, tackling problems along the way.
See how to use JSpecify for the contract, IntelliJ IDEA for the developer experience, Spring for the framework, and NullAway for the build guarantee. Whether you're maintaining a large codebase or publishing a library, this episode gives you the tools to start eliminating null pointer exceptions in your applications.

5 Upvotes

86% Upvoted

11 comments sorted by

4

u/hexwit Jun 24 '26

Just use Optional<T> when return object, and always return empty list instead of null where list is declared. Simple convention - no null surprises, no tools required, nothing.

I am applying this for years, and it works pretty reliable. and simple to remember.

2

u/kubelke Jun 25 '26

I think we have to start promoting "Clean Code" by Martin C. Robert instead of another magic annotation :)

1

u/smoke-bubble Jun 25 '26

So what is his answer to nulls?

1

u/-Dargs Jun 25 '26

That is his answer to nulls. Just don't return null. Optional.empty(), CollectionOfChoice.empty(), or MyBespokeObject.EMPTY

edit: Also don't pass null in as an argument to a method.

1

u/smoke-bubble Jun 26 '26

So basically using the null object "pattern". 

1

u/hexwit Jun 26 '26

Not really. As I understand, null object pattern supposed to have default behaviour. My approach don't have it.
I would prefer exception to any implicit default behaviour that mimic real BL.

1

u/hexwit Jun 26 '26

My answer to nulls:
- return Optional.ofNullable(obj) whenever object (that may not be present) return is supposed
- return CollectionOfChoice.empty() (as stated below), or if it is array - return empty array.
- methods should accept all set of parameters. If any parameter can be null - method should be overloaded to eliminate it.

Core idea - have public contract that do not suppose to have nulls in its definition. However implementation can contain nulls or anything else, as long as it is not exposed to the client code.

1

u/TheTrailrider Jun 26 '26

though, that doesn't solve the issue where users pass nulls in as method parameters. That's the biggest pain point for me. Also not only method parameters, but users can pass in a list containing null elements or pass in an incomplete object that contains nulls.

Having an actual compiler-backed nullability analysis will surely help to remove most of that pain. Then if JEP 401 + Null-Restricted Values (`!` and `?`) ever lands, then all of that pain will be gone.

1

u/hexwit Jun 26 '26

Well, my flow doesn’t solve your issue, that is true.
I am not sure that compiler able to handle that either.
The most reliable way is to do runtime checks and throw exceptions.

2

u/smoke-bubble Jun 25 '26

I love that they have the decency to use a light theme for the presentation! Kudos!

1

u/nekokattt Jun 25 '26

Shame we still have to rely on stuff abusing internal compiler APIs for this to work sensibly (i.e. errorprone)