LINUX.ORG.RU

Разработка JDK 8 достигла стадии Developer Preview

 ,


0

2

Mark Reinhold объявил в своем блоге, что разработка Java 8 перешла в стадию Developer Preview.

Начиная с Milestone 8 предлагается включиться в открытое тестирование jdk для ускорения процесса выявления оставшихся мелких ошибок, и усиления обратной связи с разработчиками. Предлагается скачать JDK и сообщать в bug-reporting channel в следующих случаях:

  • Имеющийся код не компилируется под JDK8.
  • Скомпилированный код выполняется медленнее, чем под прошлыми JVM.
  • JVM крашится.
  • Остались предложения по изменению дизайна языка и структуры API.

Полный список нововведений

>>> Подробности

★★★★★

Проверено: maxcom ()
Последнее исправление: maxcom (всего исправлений: 4)
Ответ на: комментарий от Legioner

С чего это вдруг? Очень удобная фича.

Функция перестает быть чистой.

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

Не следил за развитием JVM. Она уже умеет размещать объекты в стеке?

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

Но, допустим, компилятор смог узнать, что время жизни замыкания меньше времени жизни функции, и MutableInteger таки можно разместить в стеке. В чем проблема тогда?

pitekantrop ★★★
()
Ответ на: комментарий от pitekantrop

Функция перестает быть чистой.

Я не считаю хаскель эталоном функциональности и не считаю иммутабельность необходимым признаком функционального языка. Это отдельная фича со своими плюсами и минусами. Тот же лисп прекрасно обходится без иммутабельности. Джаваскрипт — тоже. Функциональность это способность оперировать функциями, как объектами первого порядка, вот и всё. А если язык не дает изменять захватываемые переменные, это его ограничение т.к. никаких плюсов это не прибавляет.

Legioner ★★★★★
()
Ответ на: комментарий от pitekantrop

Не следил за развитием JVM. Она уже умеет размещать объекты в стеке?

Примитивы — умеет. Ссылку на объект тоже умеет. Если мы хотим мутабельную ссылку на объект, придется делать еще один вспомогательный объект.

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

В общем то можно отследить дальнейшую судьбу замыкания. Чаще всего это будет какой-нибудь map или filter, который очевидно замыкание нигде не сохранит.

Но, допустим, компилятор смог узнать, что время жизни замыкания меньше времени жизни функции, и MutableInteger таки можно разместить в стеке. В чем проблема тогда?

Уже писал, что имел в виду примитивы и ссылки, а не объекты. Не знаю насчет размещения объектов в стеке.

Legioner ★★★★★
()
Ответ на: комментарий от Legioner

не считаю иммутабельность необходимым признаком функционального языка. Это отдельная фича со своими плюсами и минусами

никому эти функциональный языки не нужны сами по себе. прекрасно в 90-х годах обходились без них и в мобилках/эмбеде и так обходятся. потребность достать функциональщину из ветхих чуланов появилась из-за массового паралеллизма, когда Intel в последние годы с 2005го или примерно тогда, перестал наращивать частоту процев и стал везде и всюду пропихивать многоядерность. и функциональщину вытащили из-за единственной фичи: иммутабельности, именно благодаря ей проще писать многопоточные программы

Karapuz ★★★★★
() автор топика
Ответ на: комментарий от Legioner

Примитивы — умеет. Ссылку на объект тоже умеет. Если мы хотим мутабельную ссылку на объект, придется делать еще один вспомогательный объект.

Локальные переменные примитивных типов и ссылки на объекты всю жизнь были в стеке. Наоборот, покажи, как их в heap запихнуть.

В общем то можно отследить дальнейшую судьбу замыкания. Чаще всего это будет какой-нибудь map или filter, который очевидно замыкание нигде не сохранит.

На этапе компиляции это не понятно. С жабской динамической линковкой следить придётся в рантайме.

Немутабельные переменные копируются в поля объекта-замыкания. Так что они тоже не только в стеке память занимают.

pitekantrop ★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.