Я не зря написал про допущение, что коллекции не содержат null, потому как в обоих примерах, если будет null, то будет NPE и я с этим фактом не спорю, но я пытался объяснить почему findFirst не возвращает null, а возвращает Optional. Это один момент, а второй момент, что в javadoc к методу findFirst написано, что метод может выбросить NPE и это говорит о том, что у создателей API были на то причины. Другой вопрос, что нам такое положение вещей может не нравится и поэтому появляются альтернативы по типу vavr .
Ироничным выглядит тот факт, что код, который Стюарт приводит в качестве примера безопасного использования Optional для предотвращения NPE (время 9:38) лишен проверки на null там где она нужна. В итоге код подвержен NPE прямо "из коробки", даже без малейших его изменений
Думаю, что код, который Стюарт привёл как пример, написан с допущением, что коллекция не содержит null, так как мы не видим контекста в котором будет вызываться этот метод. А так то можно и вместо custList передать null и получить NPE.
На пустом стриме/коллекции они вернут Optional.empty(), а значение (хоть оно и null, ! но это значение !), приведет к трудноуловимому NPE. Конечно это баг особенность Stream, но и "вина" Optional тут имеется. Ведь если бы Optional не существовало, то findFirst() просто вернул бы null как first значение.
Так как findFirst возвращает Optional, то можно написать вот такой код (пример синтетический):
var result = players.stream()
.filter(player -> player.getScore() > 100)
.findFirst()
.map(Player::getData)
.map(History::filterData)
.map(History::processData)
.orElseGet(Collections::emptyList);
В случае если бы findFirst возвращал null, то код оброс бы проверками c if и красивой цепочки не получилось. Считаем, что коллекция players не содержит null значений, но можно конечно сделать фильтрацию по ним, если уж режет глаз.
Самообучение это конечно очень важная вещь, но статья полна неточностей, заблуждений и незнания матчасти. К примеру про Optional
Optional у меня может быть null`ом. Да может, и это его логичное на мой взгляд применение. Не нашли значение — опционал == null, нашли значение, опционал его содержит (даже если оно null), иначе какая польза от этого опционала? Да никакой!
Я не зря написал про допущение, что коллекции не содержат null, потому как в обоих примерах, если будет null, то будет NPE и я с этим фактом не спорю, но я пытался объяснить почему findFirst не возвращает null, а возвращает Optional. Это один момент, а второй момент, что в javadoc к методу findFirst написано, что метод может выбросить NPE и это говорит о том, что у создателей API были на то причины. Другой вопрос, что нам такое положение вещей может не нравится и поэтому появляются альтернативы по типу vavr .
Думаю, что код, который Стюарт привёл как пример, написан с допущением, что коллекция не содержит null, так как мы не видим контекста в котором будет вызываться этот метод. А так то можно и вместо custList передать null и получить NPE.
Так как findFirst возвращает Optional, то можно написать вот такой код (пример синтетический):
В случае если бы findFirst возвращал null, то код оброс бы проверками c if и красивой цепочки не получилось. Считаем, что коллекция players не содержит null значений, но можно конечно сделать фильтрацию по ним, если уж режет глаз.
Самообучение это конечно очень важная вещь, но статья полна неточностей, заблуждений и незнания матчасти. К примеру про Optional
Советую посмотреть про Optional у Stuart Marks https://www.youtube.com/watch?v=fBYhtvY19xA&ab_channel=Devoxx и сразу многое прояснится.
И такого у вас много...
Кстати для "гонок" производительности стоит попробовать написать микробенчмарк с помощью JMH. Благо статей по нему много .
P.S. Статью стоит перечитать и переписать, что должно принести не меньшую пользу.