Optional

NullPointerException - одна из самых раздражающих вещей в Java мире, которую был призван решить Optional. Нельзя сказать, что проблема полностью ушла, но мы сделали большие шаги. Множество популярных библиотек и фреймворков внедрили Optional в свою экосистему. Например, JPA Specification возвращает Optional вместо null.

Я думаю, что некоторые программисты настолько впечатлились теми возможностями, которые предоставляет Optional, что они стали использовать его даже там, где это не нужно, зачастую применяя неправильные паттерны. В этой статье я привел некоторые ошибочные использования этой монады и предложил свой путь для решения возникших проблем.

Optional не должен равняться null

Мне кажется, никаких дополнительных объяснений здесь не требуется. Присваивание null в Optional разрушает саму идею его использования. Никто из пользователей вашего API не будет проверять Optional на эквивалентность с null. Вместо этого следует использовать Optional.empty().

Знайте API

Optional обладает огромным количеством фичей, правильное использование которых позволяет добиться более простого и понятного кода.

public String getPersonName() {    Optional<String> name = getName();    if (name.isPresent()) {        return name.get();    }    return "DefaultName";}

Идея проста: если имя отсутствует, вернуть значение по умолчанию. Можно сделать это лучше.

public String getPersonName() {    Optional<String> name = getName();    return name.orElse("DefautName");}

Давайте рассмотрим что-нибудь посложнее. Предположим, что мы хотим вернуть Optional от имени пользователя. Если имя входит в список разрешенных, контейнер будет хранить значение, иначе нет. Вот многословный пример.

public Optional<String> getPersonName() {    Person person = getPerson();    if (ALLOWED_NAMES.contains(person.getName())) {        return Optional.ofNullable(person.getName());    }    return Optional.empty();}

Optional.filter упрощает код.

public Optional<String> getPersonName() {    Person person = getPerson();    return Optional.ofNullable(person.getName())                   .filter(ALLOWED_NAMES::contains);}

Этот подход стоит применять не только в контексте Optional, но ко всему процессу разработки.

Если что-то доступно из коробки, попробуйте использовать это, прежде чем пытаться сделать свое.

Отдавайте предпочтение контейнерам "на примитивах"

В Java присутствуют специальные не дженерик Optional классы: OptionalInt, OptionalLong и OptionalDouble. Если вам требуется оперировать примитивами, лучше использовать вышеописанные альтернативы. В этом случае не будет лишних боксингов и анбоксингов, которые могут повлиять на производительность.

Не пренебрегайте ленивыми вычислениями

Optional.orElse это удобной инструмент для получения значения по умолчанию. Но если его вычисление является дорогой операцией, это может повлечь за собой проблемы с быстродействием.

public Optional<Table> retrieveTable() {    return Optional.ofNullable(constructTableFromCache())                   .orElse(fetchTableFromRemote());}

Даже если таблица присутствует в кэше, значение с удаленного сервера будет запрашиваться при каждом вызове метода. К счастью, есть простой способ избежать этого.

public Optional<Table> retrieveTable() {    return Optional.ofNullable(constructTableFromCache())                   .orElseGet(this::fetchTableFromRemote);}

Optional.orElseGet принимает на вход лямбду, которая будет вычислена только в том случае, если метод был вызван на пустом контейнере.

Не оборачивайте коллекции в Optional

Хотя я и видел такое не часто, иногда это происходит.

public Optional<List<String>> getNames() {    if (isDevMode()) {        return Optional.of(getPredefinedNames());    }    try {        List<String> names = getNamesFromRemote();        return Optional.of(names);    }    catch (Exception e) {        log.error("Cannot retrieve names from the remote server", e);        return Optional.empty();    }}

Любая коллекция является контейнером сама по себе. Для того чтобы показать отсутствие элементов в ней, не требуется использовать дополнительные обертки.

public List<String> getNames() {    if (isDevMode()) {        return getPredefinedNames();    }    try {        return getNamesFromRemote();    }    catch (Exception e) {        log.error("Cannot retrieve names from the remote server", e);        return emptyList();    }}

Чрезмерное использование Optional усложняет работу с API.

Не передавайте Optional в качестве параметра

А сейчас мы начинаем обсуждать наиболее спорные моменты.

Почему не стоит передавать Optional в качестве параметра? На первый взгляд, это позволяет избежать NullPointerException, так ведь? Возможно, но корни проблемы уходят глубже.

public void doAction() {    OptionalInt age = getAge();    Optional<Role> role = getRole();    applySettings(name, age, role);}

Во-первых, API имеет ненужные границы. При каждом вызове applySettings пользователь вынужден оборачивать значения в Optional. Даже предустановленные константы.

Во-вторых, applySettings обладает четырьмя потенциальными поведениями в зависимости от того, являются ли переданные Optional пустыми, или нет.

В-третьих, мы понятия не имеем, как реализация интерпретирует Optional. Возможно, в случае пустого контейнера происходит простая замена на значение по умолчанию. Может быть, выбрасывается NoSuchElementException. Но также вероятно, что наличие или отсутствие данных в монаде может полностью поменять бизнес-логику.

Если взглянуть на javadoc к Optional, можно найти там интересную заметку.

Optional главным образом предназначен для использования в качестве возвращаемого значения в тех случаях, когда нужно отразить состояние "нет результата" и где использование null может привести к ошибкам.

Optional буквально символизирует нечто, что может содержать значение, а может нет. Передавать возможное отсутствие результата в качестве параметра звучит как плохая идея. Это значит, что API знает слишком много о контексте выполнения и принимает те решения, о которых не должен быть в курсе.

Что же, как мы можем улучшить этот код? Если age и role должны всегда присутствовать, мы можем легко избавиться от Optional и решать проблему отсутствующих значений на верхнем уровне.

public void doAction() {    OptionalInt age = getAge();    Optional<Role> role = getRole();    applySettings(name, age.orElse(defaultAge), role.orElse(defaultRole));}

Теперь вызывающий код полностью контролирует значения аргументов. Это становится еще более критичным, если вы разрабатываете фреймворк или библиотеку.

С другой стороны, если значения age и role могут быть опущены, вышеописанный способ не заработает. В этом случае лучшим решением будет разделение API на отдельные методы, удовлетворяющим разным пользовательским потребностям.

void applySettings(String name) { ... }void applySettings(String name, int age) { ... }void applySettings(String name, Role role) { ... }void applySettings(String name, int age, Role role) { ... }

Возможно это выглядит несколько многословно, но теперь пользователь может сам решить, какой метод вызвать, избегая непредвиденных ошибок.

Не используйте Optional в качестве полей класса

Я слышал разные мнения по этому вопросу. Некоторые считают, что хранение Optional напрямую в полях класса позволяет сократить NullPointerException на порядок. Мой друг, который работает в одном известном стартапе, говорит, что такой подход в их компании является утвержденным паттерном.

Хотя хранение Optional в полях класса и звучит как хорошая идея, я думаю, что это может принести больше проблем, чем пользы.

Отсутствие сериализуемости

Optional не имлементирует интерфейс Serializable. Это не баг, это намеренное решение, так как данный класс был спроектирован для использования в качестве возвращаемого значения. Проще говоря, любой объект, который содержит хотя одно Optional поле, нельзя сериализовать.

На мой взгляд, этот аргумент является наименее убедительным, так как сейчас, в мире микросервисов и распределенных систем, платформенная сериализация не является настолько важной, как раньше.

Хранение лишних ссылок

Optional это объект, который необходим пользователю всего несколько миллисекунд, после чего он может быть безболезненно удален сборщиком мусора. Но если мы храним Optional в качестве поля, он может оставаться там вплоть до самой остановки программы. Скорее всего, вы не заметите никаких проблем с производительностью на маленьких приложениях. Однако, если речь идет о большом сервисе с дюжинами бинов, последствия могут быть другие.

Плохая интеграция со Spring Data/Hibernate

Предположим, что мы хотим построить простое Spring Boot приложение. Нам нужно получить данные из таблицы в БД. Сделать это очень просто, объявив Hibernate сущность и соответствующий репозиторий.

@Entity@Table(name = "person")public class Person {    @Id    private long id;    @Column(name = "firstname")    private String firstName;    @Column(name = "lastname")    private String lastName;        // constructors, getters, toString, and etc.}public interface PersonRepository extends JpaRepository<Person, Long> {}

Вот возможный результат для personRepository.findAll().

Person(id=1, firstName=John, lastName=Brown)Person(id=2, firstName=Helen, lastName=Green)Person(id=3, firstName=Michael, lastName=Blue)

Пусть поля firstName и lastName могут быть null. Мы не хотим иметь дело с NullPointerException, так что просто заменим обычный тип поля на Optional.

@Entity@Table(name = "person")public class Person {    @Id    private long id;    @Column(name = "firstname")    private Optional<String> firstName;    @Column(name = "lastname")    private Optional<String> lastName;        // constructors, getters, toString, and etc.}

Теперь все сломано.

org.hibernate.MappingException: Could not determine type for: java.util.Optional, at table: person,       for columns: [org.hibernate.mapping.Column(firstname)]

Hibernate не может замапить значения из БД на Optional напрямую (по крайней мере, без кастомных конвертеров).

Но некоторые вещи работают правильно

Должен признать, что в конечном итоге не все так плохо. Некоторые фреймворки корректно интегрируют Optional в свою экосистему.

Jackson

Давайте объявим простой эндпойнт и DTO.

public class PersonDTO {    private long id;    private String firstName;    private String lastName;    // getters, constructors, and etc.}

@GetMapping("/person/{id}")public PersonDTO getPersonDTO(@PathVariable long id) {    return personRepository.findById(id)            .map(person -> new PersonDTO(                    person.getId(),                    person.getFirstName(),                    person.getLastName())            )            .orElseThrow();}

Результат для GET /person/1.

{  "id": 1,  "firstName": "John",  "lastName": "Brown"}

Как вы можете заметить, нет никакой дополнительной конфигурации. Все работает из коробки. Давайте попробует заменить String на Optional<String>.

public class PersonDTO {    private long id;    private Optional<String> firstName;    private Optional<String> lastName;    // getters, constructors, and etc.}

Для того чтобы проверить разные варианты работы, я заменил один параметр на Optional.empty().

@GetMapping("/person/{id}")public PersonDTO getPersonDTO(@PathVariable long id) {    return personRepository.findById(id)            .map(person -> new PersonDTO(                    person.getId(),                    Optional.ofNullable(person.getFirstName()),                    Optional.empty()            ))            .orElseThrow();}

Как ни странно, все по-прежнему работает так, как и ожидается.

{  "id": 1,  "firstName": "John",  "lastName": null}

Это значит, что мы можем использовать Optional в качестве полей DTO и безопасно интегрироваться со Spring Web? Ну, вроде того. Однако есть потенциальные проблемы.

SpringDoc

SpringDoc это библиотека для Spring Boot приложений, которая позволяет автоматически сгенерировать Open Api спецификацию.

Вот пример того, что мы получим для эндпойнта GET /person/{id}.

"PersonDTO": {  "type": "object",  "properties": {    "id": {      "type": "integer",      "format": "int64"    },    "firstName": {      "type": "string"    },    "lastName": {      "type": "string"    }  }}

Выглядит довольно убедительно. Но нам нужно сделать поле id обязательным. Это можно осуществить с помощью аннотации @NotNull или @Schema(required = true). Давайте добавим кое-какие детали. Что если мы поставим аннотацию @NotNull над полем типа Optional?

public class PersonDTO {    @NotNull    private long id;    @NotNull    private Optional<String> firstName;    private Optional<String> lastName;    // getters, constructors, and etc.}

Это приведет к интересным результатам.

"PersonDTO": {  "required": [    "firstName",    "id"  ],  "type": "object",  "properties": {    "id": {      "type": "integer",      "format": "int64"    },    "firstName": {      "type": "string"    },    "lastName": {      "type": "string"    }  }}

Как видим, поле id действительно добавилось в список обязательных. Так же, как и firstName. А вот здесь начинается самое интересное. Поле с Optional не может быть обязательным, так как само его наличие говорит о том, что значение потенциально может отсутствовать. Тем не менее, мы смогли запутать фреймворк с помощью всего лишь одной лишней аннотации.

В чем здесь проблема? Например, если кто-то на фронтенде использует генератор типов сущностей по схеме Open Api, это приведет к получению неверной структуры, что в свою очередь может привести к повреждению данных.

Решение

Что же нам делать со всем этим? Ответ прост. Используйте Optional только для геттеров.

public class PersonDTO {    private long id;    private String firstName;    private String lastName;        public PersonDTO(long id, String firstName, String lastName) {        this.id = id;        this.firstName = firstName;        this.lastName = lastName;    }        public long getId() {        return id;    }        public Optional<String> getFirstName() {        return Optional.ofNullable(firstName);    }        public Optional<String> getLastName() {        return Optional.ofNullable(lastName);    }}

Теперь этот класс можно безопасно использовать и как сущность Hibernate, и как DTO. Optional никак не влияет на хранимые данные. Он только оборачивает возможные null, чтобы корректно отрабатывать отсутствующие значения.

Однако у этого подхода есть один недостаток. Его нельзя полностью интегрировать с Lombok. Optional getters не подерживаются библиотекой и, судя по некоторым обсуждениям на Github, не будут.

Я писал статью по Lombok и я думаю, что это прекрасный инструмент. Тот факт, что он не интегрируются с Optional getters, довольно печален.

На текущий момент единственным выходом является ручное объявление необходимых геттеров.

Заключение

Это все, что я хотел сказать по поводу java.util.Optional. Я знаю, что это спорная тема. Если у вас есть какие-то вопросы или предложения, пожалуйста, оставляйте свои комментарии. Спасибо за чтение!