Ява.утиль.Объекты vs необязательно, что предпочтительнее?

самый короткий ответ на ваш вопрос "что предпочтительнее?"является любимым разработчиком всех времен "это зависит", потому что Objects::requireNonNullElse и Optional охватывают различные варианты использования.

Две Альтернативы

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

Objects::requireNonNullElse

Objects::requireNonNull гарантирует, что результат вызова никогда не будет нулевым (отсюда и имя). Он обычно используется для краткой проверки конструктор или метод аргументов и позволяет читателям проверить с первого взгляда, что переменная, которой назначено возвращаемое значение не может быть null.

так что это было бы не только странно для Objects::requireNonNullElse чтобы вдруг позволить null, это также было бы бесполезно, потому что:

// if requireNonNullGet would allow null as second argument,
// the following is true for all x (including null)
Objects.requireNonNullElse(x, null) == x

вы можете утверждать, что это отличается для requireNonNullElseGet потому что это может вызвать функцию, которая в зависимости от какого-либо государства, может вернуть null или нет. Это правда, и я предполагаю, что это было считается, но requireNonNull... API было бы очень странно, если бы один из трех случаев мог фактически позволить конечному результату вызова быть null хотя имя говорит требуется non null.

Optional

Optional разработан в качестве аргумента возврата в случаях, когда returning null очень вероятно, что вызовет NPEs (например, для Streamтерминальная деятельность, где она сперва была использована). Хотя некоторые разработчики предпочитают использовать его в больше случаев (сравните Стивен Коулберн это и мой строгий подход) никто не предлагает использовать его, как в вашем демонстрации:

Optional.ofNullable(nullStr).orElse(null);
Optional.ofNullable(nullStr).orElseGet(() -> null);

Optional - это способ выразить в системе типов, что что-то может отсутствовать - это не означает, как альтернативу if-null-проверяет. В этом смысле orElse или orElseGet являются бэкдоры из Optional назад в мир nullable типов и иногда null это просто то, что вы хотите использовать, если чего-то нет, поэтому имеет смысл для них принять null в качестве аргумента (или результат поставщика).

Вопросы

теперь у нас есть то, что нам нужно, чтобы ответить на ваши вопросы:

Почему разработчики JDK не обновили существующие методы в необязательном классе?

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

почему они не ввели новый метод (который будет брошен NPE, если второй аргумент равен null) в необязательный класс?

API расширяются только в том случае, если можно ожидать значительных улучшений существующего кода. Здесь я этого не вижу. Во многих случаях orElse получает аргумент, который вызывающий объект создает специально в качестве альтернативы для пустых optionals-редко возникает необходимость сделать дополнительную проверку, чтобы убедиться, что это не null. Если вам действительно нужно, позвоните orElse(requireNonNull(x)).

что мы должны использовать теперь необязательно или объекты?

если у вас есть переменная (будь то локальная, аргумент или поле), и вы хотите убедиться, что это не null, используйте Objects. Если вы хотите вернуть что-то, что может быть null оборачивать его в Optional. Будьте подозрительны к коду, который создает Optional (в отличие от получения одной формы вызова) и разворачивает его на конец той же цепи.

новые методы делают объекты более предпочтительными, чем необязательными, поскольку они будут бросать NPE немедленно, а не позже где-то в коде, как с необязательным?

как я уверен, теперь ясно, они охватывают различные варианты использования. Но позвольте мне обратиться "и не позже где-то в коде, как с необязательным": что бы вы ни делали, обязательно проверьте желаемое свойство nullablity (может быть null или нет) в ваш код. Не вернуть то, что вы предполагаете, не может быть null но это, оказывается, потому что вы не проверить. Если это произойдет, это не Optionalвина.

если у меня есть легаси код, что-то вроде:

String str = null; 
String result = str == null ? "other string" : str;

наверняка Objects.requireNonNullOrElse(str,"other string); и рассмотреть возможность использования статического импорта, чтобы сделать его более читабельным.