lambdaj действительно не предлагает лямбда-выражений
Это верно.
[lambdaj] предоставляет некоторые из тех же функций, например, закрытие
Если под этим вы имеете в виду «он обеспечивает закрытие», то нет. Замыкание не может существовать без лямбда-выражения; на самом деле это частный случай лямбда-выражения, который является наиболее сложным для реализации.
К сожалению, проектная документация LambdaJ вводит в заблуждение, применяя термин «закрытие» к чему-то, что не соответствует требованиям. Пример со страницы вики Closures:
Closure println = closure(); { of(System.out).println(var(String.class)); }
За примером следует такое объяснение:
В частности, метод var() связывает свободную переменную типа String с замыканием.
Это утверждение просто неверно: там вообще не происходит привязки переменных, не говоря уже о свободной переменной. Конструкция приводит к чему-то похожему на унарную функцию, которая ожидает String аргумент. (Ну, на самом деле он ожидает Object, но завершится ошибкой во время выполнения, если передано значение, отличное от String.)
С другой стороны, вызов of() в примере действительно идет немного в направлении захвата локальной переменной. Можно сказать, что аргумент, переданный of(), захватывается возвращаемым им объектом. Однако мы не можем ссылаться на него в дальнейшем синтаксисе; это просто неявная цель последующего вызова метода. Это далеко от полного закрытия.
Мне интересно, что лямбда-выражения 1.8 могут привнести в проект Java, а лямбда-выражения - нет. Это просто вопрос повышения производительности за счет встроенной поддержки анонимных функций?
Поскольку LambdaJ не предоставляет возможности писать анонимные функции, технически на этот вопрос нет ответа. Однако будьте уверены, что замыкания Java 8 превзойдут LambdaJ в зависимости от варианта использования, потому что LambdaJ в основном основан на отражении, тогда как замыкания Java вообще не нуждаются в этом.
Будут ли в 1.8 присутствовать выражения, подобные функциям манипулирования коллекциями lambdaj?
Безусловно, и поддержка очень серьезная и полная. Есть как дополнительные функции, так и функции, которые можно компоновать. Возможности LamdaJ ничтожны по сравнению с тем, что готово к использованию в Java 8. Ознакомьтесь с Streams API.
Одна из основных целей разработки Streams API никогда даже не предназначалась для реализации LambdaJ: автоматическое распараллеливание обработки. Конечно, обработка коллекций, ориентированная на FP, выглядит лучше, чем императивная идиома, но это гораздо больше, чем просто внешний вид: это фундаментальное изменение. Это ставка Java на будущее вычислений, где единственный способ повысить производительность - задействовать больше параллельных потоков обработки.
person
Marko Topolnik
schedule
28.01.2014
