Закрытия в Java 7 [дубликат]

Да, в план выпуска были включены закрытия java 7 (и это была самая важная причина отложить выпуск с зимы на осень (ожидается в сентябре 2010 г.)).

Последние новости можно найти на Project Lambda . Вам также может быть интересно прочитать последний проект спецификации .

Последние новости - AFAIK по-прежнему на конец ноября 2009 года, что закрытия будут в Java 7 в той или иной форме. Поскольку это было основной причиной значительной задержки выпуска, маловероятно, что они откажутся от него снова.

http://java.dzone.com/news/closures-coming-java-7

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

На данный момент нет официального заявления о состоянии закрытия.

Вот несколько читаемых примеров того, как это могло бы работать и выглядеть.

Если вы хотите получить представление о том, что происходит, я отсылаю вас к списку рассылки OpenJDK .

Обзор

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

Сообщение об изменении от Маурицио Чимадамора гласит:

начальное нажатие лямбда; текущий прототип поддерживает следующие функции:

• синтаксис типов функций (опционально включен с помощью -XDallowFunctionTypes)
• подтипы типов функций
• полная поддержка лямбда-выражений типов 1 и 2
• вывод выброшенных типов / возвращаемого типа в лямбда-преобразовании
• лямбда-преобразования с использованием правил, указанных в v0.1.5 черновике
• , поддерживаются ссылки на 'this' (как явные, так и неявные)
• перевод с использованием дескрипторов методов

Модифицированная сборка сценария репозиторий langtools теперь генерирует дополнительный файл jarfile с именем javacrt.jar который содержит вспомогательный класс, который должен быть используется при конвертации SAM; после build, сгенерированные скрипты javac / java позаботится о автоматическая настройка необходимого зависимости, так что код, содержащий лямбда-выражения могут быть скомпилированы и выполнен.

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

С отрицательной стороны есть некоторые заявления от Нила Гафтера:

Прошло почти три месяца с момента черновика 0.15, а сейчас меньше чем за две недели до окончательной интеграции TL (Инструменты и языки) предыдущая функция openjdk7 завершена. Если вы добились прогресса в спецификации и реализации, мы были бы очень признательны за то, чтобы поделился с нами. Если нет, возможно, мы сможем помочь.Если Oracle решил, что эта функция больше не важна для JDK7, что было бы хорошо знать тоже. Что бы ни происходило, тишина посылает неверный сигнал.

дискуссия между Нилом Гафтером и Джонатаном Гиббонсом:

Рад видеть это, Маурицио! К сожалению, он опаздывает на неделю, и в неправильном репозитории, чтобы включить его в jdk7.

Я заметил, что ни один из тестов не показывает, что переменная типа функции преобразован в тип SAM. Какие там планы? ответ Джонатана Гиббонса : Поскольку опубликованный список функций для jdk7 и опубликованное расписание для jdk7 может показаться несовместимым, почему вы всегда предполагаете, что расписание верно? Ответ Нила Гафтера : Потому что я припоминаю неоднократные дискуссии о том, что набор функций будут скорректированы в зависимости от их статуса завершения в отношении расписание.

Некоторые люди даже задаются вопросом, имеет ли все это смысл больше, и предлагают перейти на другой язык :

Возникает вопрос, почему бы просто не перейти на Scala - это гораздо больше который необходимо добавить в Java, чтобы создать последовательную комбинацию функций вокруг лямбд. А теперь эти задержки, которые затрагивают не только пользователи ParallelArray, но все, кто хочет создавать, подверглись аккуратному рефакторингу, тестируемое программное обеспечение на Java.

Похоже, никто не предлагает добавить в Java отклонение от места объявления. => означает, что интерфейсы FunctionN не будут подтипировать должным образом. Для примитивов нет и специализации.(@Specialized в Scala - сломан для всех классов, кроме игрушечных, но, по крайней мере, он движется вправо direction)

Отсутствие распознавания на уровне JVM того, что объект является замыканием и, следовательно, может быть устранено, как это может быть с устранением закрытия в Scala (если HOF может также быть встроенным.) JVM, кажется, добавляет что-то вроде неизбежной машины доступ к каждому полиморфному сайту вызова, даже если они предположительно встроенное кэширование и не мегаморфизм, даже внутри цикла.Результат, что у меня видно примерно вдвое замедление игрушечных микробенчмарков, таких как "суммировать массив целых чисел ", если реализовано с любой формой замыкания, кроме чего-то это может быть @ inline'd в Scala. (И даже в Scala большинство HOF являются виртуальными следовательно, не может быть встроен.) Я, например, хотел бы видеть полезное встраивание в язык, который / поощряет / использование замыканий в каждом цикле for.

Заключение

Это всего лишь краткий обзор всей происходящей проблемы, и цитаты и утверждения не являются исчерпывающими. В настоящий момент люди все еще задаются вопросом: «Можно ли на самом деле делать замыкания на Java, и если да, то как это должно быть сделано и как это может выглядеть?».

Не существует простого типа «Хорошо, мы просто добавим закрытия для Java на выходных». Из-за взаимодействия некоторых ошибок дизайна, таких как varargs как массивы, стирание типа ... есть случаи, которые просто не работают. Найти все эти мелкие проблемы и решить, можно ли их исправить, довольно сложно.

В конце концов, могут быть некоторые сюрпризы. Я не уверен, что это будет за сюрприз, но я предполагаю, что это будет либо:

• Замыкания не попадут в Java 7, либо
• Замыкания в Java 7 будут такими же, как Generics в Java 5 (Багги, сложные кажется, что это может сработать, но распадается, как только вы продвинетесь немного дальше)

Личное мнение

Я перешел на Scala давным-давно. Пока Oracle не делает глупостей с JVM, мне все равно. В процессе эволюции языка Java были допущены ошибки, отчасти из-за обратной совместимости. Это создавало дополнительную нагрузку с каждым новым изменением, которое пытались внести люди.

В основном: Java работает, но эволюции языка больше не будет. Каждое изменение, вносимое людьми, увеличивает стоимость следующего изменения, делая изменения в будущем все более и более маловероятными. Я не верю, что после Java 7 произойдут какие-либо изменения в языке Java, за исключением небольших улучшений синтаксиса, таких как проект Coin.