История изменений
Исправление 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
- довольно странное решение на мой взгляд