Comments 4
Это все наивно и хорошо только в теории. Вот описываем мы поля как nonnull, а потом в ход вступает десериализатор, который автоматически парсит пользовательский request и вот вам нулы в nonnull полях. То же самое с ORM и прочими технологиями. Требуется более глубокая поддержка nullability всем стеком.
Ну можно валидаторы прикрутить, которые бы проверяли после десериализации. Мы так и делаем.
Смысл этих аннотаций - отлавливать null-refs во время компиляции (сборки).
Валидаторы тут совершенно ни при чем.
При чём - комментарий был про создание объекта не из кода, а автоматически, десериализовывая. Т.е. вот у вас pojo с nonnull и всё хорошо. Но этот объект создаётся не вами в коде, а приходит из вне - json в Jackson, или строка из базы в hibernate. И вот им эти nonnull/nullable побоку. Они его создадут как есть в оригинале и ничего проверять не будут, если не попросишь. Это я ещё не говорю про нативную java serialization - там даже конструктор не вызывается.
Так вот что бы это работало нужно вручную вызывать валидацию. Это типичная проблема. Тут по сути будет nonnull Шрёдингер - пока мы валидацию не запустим, не узнаем. И до валидации ничего с объектом делать нельзя.
Null-safety в Spring приложении с JSpecify и NullAway