LINUX.ORG.RU

История изменений

Исправление borisych, (текущая версия) :

В этом случае проблем с производительностью при хранении Optional в поле объекта больше возникать не будет.

Если приглядеться, то у Optional отсутствует заветный extends Serializable, что очень часто мешает его делать полем объекта, а передавать Optional в аргументы метода мешает Type Erasure (здесь даже и не говорим о том, что конвенция - это всего лишь конвенция и никому в целом не мешает пихать или отдавать null вместо empty()). Ежели задаться вопросом, а чего это оно так, то можно найти довольно исчерпывающее объяснение: https://stackoverflow.com/a/24564612/3426309, что однако не мешает, разработчикам JDK писать откровенный .овнокод, jdk.internal.net вы уже привели в пример, в com.sun.tools.javac.comp Optional используется в качестве Lazy Supplier - довольно странное решение на мой взгляд

PS. как возвращаемое значение Optional тоже так себе: лаконичные цепочки получается построить крайне редко, а если еще и другой контейнер оборачивается, то совсем беда-беда

Исходная версия borisych, :

В этом случае проблем с производительностью при хранении Optional в поле объекта больше возникать не будет.

Если приглядеться, то у Optional отсутствует заветный extends Serializable, что очень часто мешает его делать полем объекта, а передавать Optional в аргументы метода мешает Type Erasure (здесь даже и не говорим о том, что конвенция - это всего лишь конвенция и никому в целом не мешает пихать или отдавать null вместо empty()). Ежели задаться вопросом, а чего это оно так, то можно найти довольно исчерпывающее объяснение: https://stackoverflow.com/a/24564612/3426309, что однако не мешает, разработчикам JDK писать откровенный .овнокод, jdk.internal.net вы уже привели в пример, в com.sun.tools.javac.comp Optional используется в качестве Lazy Supplier - довольно странное решение на мой взгляд