Учебники Java для Lambda Expressions говорят следующее:
В этом разделе обсуждаются функции, включенные в проект Lambda, цель которого для поддержки программирования в многоядерной среде путем добавления закрытий и связанные с ним функции на языке Java.
Мой вопрос: какие конкретные преимущества у меня есть с лямбда-выражениями в соответствии с многоядерными системами и параллельным/параллельным программированием?
Parallelism тривиально для реализации, например. если у вас есть коллекция, и вы реализуете лямбду таким образом:
collection.map { // my lambda }
то сама коллекция может распараллеливать эту операцию без необходимости делать нить и т.д. самостоятельно. parallelism обрабатывается в рамках реализации коллекции map().
В чисто функциональной (т.е. без побочных эффектов) системе вы можете сделать это для каждой лямбды. Для не чисто функциональной среды вам нужно будет выбрать лямбды, для которых это будет применяться (поскольку ваша лямбда не может работать безопасно параллельно). например в Scala вам необходимо явно использовать параллельный вид в коллекции для реализации вышеизложенного.
Некоторые справочные материалы:
С полным уважением к Java лямбда-функции и намерениям o разработчикам я хотел бы спросить: что нового и почему это лучше, чем традиционный подход к функции интерфейса/метода? Почему это лучше, чем (предположим) forEach(IApply) где:
IApply является интерфейсом
public interface IApply {
void exec(KEY key, VALUE value);
}
Как это мешает parallelism? По крайней мере реализация IApply может быть повторно использована, унаследована (расширенна), реализована в статическом классе.
Последний аргумент важен после десятков примеров ошибок юниоров, которые я видел, которые пропускают этот лямбда-код, обращаясь к этому из внешнего класса, может быть причиной того, что класс остается в памяти после того, как отдельная ссылка на него уже нулевая.
С этой точки зрения очень важны ссылки на статические члены класса (являются аналогами случая С# "делегат". И главным образом - из одной руки - лямбда - это суперкапсуляция, из другой - не многократно, а одновременно - нарушение основных принципов культуры OOD: свободный доступ к мастер-членам. С точки зрения культуры программирования - обратная к 70-м годам прошлого века.
Функциональное программирование? Я вижу, но почему смешивать - это феномены ООП, которые есть в Java. OOD имеет замечательный образец с разделителем Data-Behavior, который элегантно предоставляет те же возможности? Аргумент - это то же самое, что и в Java Script... nu, действительно! Поэтому дайте инструменты для встраивания Java Script в Java и напишите фрагменты системы в Java Script. Таким образом, я до сих пор не вижу действительно реальных преимуществ, так как есть волна рекламы.