Немного о Stream API(Java 8)

[@StasTs]

Я конечно сейчас получу кучу минусов, но вот это:

String campPeople = sport.stream().filter(p -> p.getName() != null).map(SportsCamp::getName).collect(Collectors.joining(" and ",«In camp »," rest all days."));

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

[@AlexeyVD]

Если добавить немного форматирования, то всё становится не так уж плохо:

String campPeople = sport.stream()
                .filter(p -> p.getName() != null)
                .map(SportsCamp::getName)
                .collect(Collectors.joining(" and ",«In camp »," rest all days."));

[@Terran37]

да, это удачное форматирование при разработке.

[@Fen1kz]

Да и при написании/прочтении статьи тоже, если честно

[@Timmmm]

Так по моему лучше

String campPeople = sport.stream()
.filter(Objects::nonNull)
.map(SportsCamp::getName)
.collect(Collectors.joining(" and ",«In camp »," rest all days."));

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

[@pullover]

Чуть подправлю:

String campPeople = sport.stream()
.map(SportsCamp::getName)
.filter(Objects::nonNull)
.collect(Collectors.joining(" and ",«In camp »," rest all days."));

[@Timmmm]

Да, конечно вы правы.

[@sshikov]

Ну, минусов-то тут не за что. Нормальный вопрос, на нормальную (хотя и далеко не новую тему).

Попробую дать свой ответ.

Те кто думает, будто манипулирование коллекциями в таком стиле легче читается, как минимум лукавят. Для кого-то может и легче, но это дело субъективное. Вопросу тут не в легкости. Дело в другом — такой функциональный стиль удобнее компонуется, потому что по сути это функции, которые можно объединять в формулы, спокойно параллелить вычисления (если данные имутабельны и нет побочных эффектов), причем правильность компоновки в значительной степени за нас проверит компилятор.

>Часто логика выбора и так слишком длинна и сложна, что приходится для читаемости разбивать на несколько строк/операторов.
Вот это в сущности и есть цель. Чтобы можно было надежно разбивать и компоновать обратно, а части были максимально повторно используемыми.

[@zzashpaupat]

Еще одна статья про Stream API, коих было уже предостаточно. Описано как-то очень сумбурно. Для людей, имеющих опыт работы со стримами — ничего нового, а для новичков — ничего не понятно.

[@Terran37]

Не могу принять Вашу точку зрения, т.к. она не подкреплена примерами.
Были комментарии выше, с которыми я полностью согласен, т.к. они аргументированы, но это не про Ваш комментарий.
Вы можете привести ссылки на огромное количество статей с работающими примерами за исключением уже имеющихся у меня в избранном?
В первых строках указано, что статья для пользователей начинающих знакомиться с данными возможностями, а не для профессионалов.
«Описано как-то очень сумбурно» — у всех свой стиль написания статей, замечу, что абсолютно все примеры рабочие и в точности показывают возможности функционала, а это немаловажно.

[@afanasiy_nikitin]

Я не даю четкого определения и точного размера коллекций

~10000 (из книги Р. Уорбертона «Лямбда-выражения в Java 8»)

[@Terran37]

У Вас будет точная формулировка этой цифры из книги? Возможно были дополнительные условия применения именно 10000?

[@afanasiy_nikitin]

Имеется в виду размер коллекции, при котором использование parallelStream действительно оправдано по производительности (поскольку, как известно, fork-join имеет некоторый оверхед на разделение/слияние потоков). Точную цитату могу поискать чуть позже. Ричард Уорбертон является одним из авторов-разработчиков данной технологии (и вообще Stream API), думаю, ему можно доверять. Книга небольшая, переведена на русский и есть в магазинах (и, к слову, в миллион раз полезнее, чем данная статья)

[@Terran37]

Понятно, что речь идет про коллекцию, и про fork/join обсуждали. Вы напишите формулировку из книги, т.к. я еще раз повторю, что коллекции бывают разные(обратите на это внимание). Книга действительно хорошая. Про полезность статьи судить не Вам(возможно, что многим примеры будут полезны).

[@grossws]

Про полезность статьи судить не Вам(возможно, что многим примеры будут полезны).

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

[@Terran37]

Данная фраза относилась к пользователю afanasiy_nikitin. Мне кажется, что я обоснованно рассказал в комментариях ниже свою точку зрения. Еще раз повторю, что если мы заявляем о фактах из книг, то мы должны в этом быть уверены. Я не поленился и перечитал(уже почти полностью) данную книгу и написал, что afanasiy_nikitin не прав и в чем, привел выдержки из книги.
Кстати, книгу всем советую, действительно отличная.

[@grossws]

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

[@Terran37]

Не ищите цитату, т.к. вот она:
«При замере времени работы примеров 6.1 и 6.2 на 4-ядерной машине при 10 альбомах последовательная версия оказывается в 8 раз
быстрее. При 100 альбомах обе версии работают одинаково быстро,
а при 10 000 альбомов параллельная версия опережает последовательную в 2,5 раза.
Все результаты измерений в этой главе приводятся только для сведения. На вашей машине они могут оказаться совершенно другими.
Размер входного потока – не единственный фактор, определяющий, даст ли распараллеливание ускорение. Результаты могут также
зависеть от способа написания кода и количества доступных ядер.»
Автор книги Ричард Уорбэртон приводит нам пример про 10000(не говоря о том, что 10000 — это идеальное число для «отсечки») и обратите внимание, что скорости могут отличаться.

[@afanasiy_nikitin]

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

[@Terran37]

1) Речь про значение в 10000 идет о альбомах (музыкальных треках).
2) Не могу понять Ваше желание сравнивать книги и статьи, приводя неправильные примеры, вводя в заблуждение читателей. Замечу. что автор книги(Ричард Уорбэртон), начиная со 107 страницы, подробно пишет о производительности при разных структурах и объемах данных. Вами сказанного значения в "~10000" у него нет.
3)Пожалуйста.

[@Terran37]

Еще раз специально перечитал несколько глав из книги Герберта Шилдта пытаясь найти упоминание о пороговых значениях, не нашел. Пытался смотреть другие источники, не нашел. Есть особенности при обработке в параллель. Первое — мы зависим от мощностей и «свободных» процессоров. Второе — коллекции представляют из себя различную структуру, поэтому необходимы точные формулировки из Вашего примера для понимания возможностей в точности разделения коллекций по определенному пороговому значению.

[@tagir_valeev]

Про 10000 — феерический бред. Ваша работа — это N*Q, где N — количество элементов, а Q — среднее время обработки элемента. Если Q очень велико, то распараллеливать имеет смысл уже при N = 2. Если Q исключительно мало (например, сложение двух чисел), то параллелизм поможет только при больших N. Кроме того, многое зависит от самих операций в стриме. Если все операции stateless, вы можете получить хороший прирост. Если имеются stateful-операции, можно сильно замедлиться даже для очень большого N. Переменных очень много.

[@tagir_valeev]

(p1,p2) -> p1.getDay().compareTo(p2.getDay())
Лучше писать Comparator.comparing(SportsCamp::getDay). Меньше вероятность ошибки.

[@Terran37]

Спасибо, учту.