Java SE 8

Например, логирование осталось там где было. Хотя мне это не мешает.

slf4j решает задачи логирования удобным образом. Если нужно что-то еще, то log4j / logback / Java logging в помощь.

Хотя реально нужных изменений нету.

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

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

Ну а кто на лямбды повелся, сидит и кушает local variables referenced from a lambda expression must be ‘effectively final’, ха-ха.

И в чем проблема?

Java защищает от «кривого» программирования. В данном случае это из за того, что лямбды могут в параллельных потоках работать. И чтобы избежать ситуации race-condition была сделана защита в виде final. Вполне себе хорошее решение.

я так понимаю что определить такую штуку нельзя:

int a = func (3, 4, +);

?

надо через интерфейс add = (a, b) -> a + b;

и только потом

int a = add (3, 4);

yoghurt

Fake.java:

interface FakeAndGay {
    void doNothing();
}

public class Fake {
    public static void main(String[] args) {
        int x = 0;
        FakeAndGay fng = () -> x++;
    }
}

javac Fake.java

Fake.java:8: error: local variables referenced from a lambda expression must be final or effectively final
        FakeAndGay fng = () -> x++;
                               ^
1 error

java -version
java version "1.8.0"

Это-то я понял, а из анонимного класса-то нельзя локальные переменные захватить?

Нет, нельзя, ведь «лямбда» и есть обертка анонимного класса.

error: local variables referenced from a lambda expression must be final or effectively final

Жалко, что в скале такого нет.

int x = 0;
FakeAndGay fng = () -> x++;

Эталонный быдлокод. Увольнял бы с последующим расстрелом. man fold и man reduce.

Это-то я понял, а из анонимного класса-то нельзя локальные переменные захватить?

Напрямую нельзя. Но есть варианты :)

Сделай final int[] x = new int[1]; и использование () -> x[0] = 5;

По большому счету локальные переменные менять из лямбды - плохо, но если совсем приспичило, то можно выкрутиться ;)

Интересно, как быстро смогут сделать интерфейс для работы с СУБД на основе лямбд (аналог Linq).

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

В тильде наверняка есть уже. Она вроде вместе с сайтом обновляется.

лямбда-функции
Stream API

От треска пердаков лиспохацкелистов начинает закладывать уши.

Баттхёрта-маргинальщиков-тред, иди!

разве в интерфейсах нельзя писать реализаций методов?

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

4.2

It’s fascinating to see how Java, the most “strict” of modern languages is now using dynamic linkage to power its new Lambda expressions. It’s also an efficient approach, as no additional class loading and compilation is needed – the Lambda method is simply another private method in our class.

http://www.takipiblog.com/2014/01/16/compiling-lambda-expressions-scala-vs-ja...

local variables referenced from a lambda expression must be ‘effectively final

Давно пишу код без переменных. Допустим на скале было бы такое же сообщение, то я о нём никогда бы и не узнал. ЧЯДНТ?

прелесть Linq не в наличии Linq-to-sql, а в том, что AST полученный из Linq-expression можно анализировать средствами самой программы, и таким образом относительно легко добавлять новые синтаксисы

а linq-to-sql-подобных библиотек для жабы гуглится сразу несколько штук, но из-за отсутствия вышеописанных функций они все работают на основе генерации кода, т.е. являются полным отстоем

разве в интерфейсах нельзя писать реализаций методов?

В трейтах — можно. В интерфейсах — нет, потому что интерфейсы. Но в java нет трейтов.

Давно пишу код без переменных. ЧЯДНТ?

пишешь на яве как на скале?

Раньше было только в non-public api.

Понял, ок.

Привык к EE API просто.

Не нужно

В трейтах — можно. В интерфейсах — нет, потому что интерфейсы. Но в java нет трейтов.

И конечно же ты жутко, отягчающе не прав.

Четай: http://zeroturnaround.com/rebellabs/java-8-explained-default-methods/

tl;dr: помечаем метод в интерфейсе как default, и пишем ему реализацию прямо как в обычном классе

Пишу на чём попало как на эрланге.

Трейт - это намного больше, чем интерфейс с реализованным методом, хотя внешне он выглядит именно так. В java мощи трейтов нет. Курим scala stackable trait pattern, trait abstract override и т.д.

Ручной резолв конфликтов default-методов по ссылке доставляет отдельно. PS: Насчет реализации в интефейсах — да, неправ.

Так я на скале и пишу. Вот раздумываю, стоит ли начать рассматривать яву как язык, после введения этих фишек из восьмерки.

Хотя, изначально на скалу подсел из-за отсутствия проклятых NullPointerExceptions и паттерн-матчинга, и не похоже что новая явка сильно поможет в этом.

http://www.takipiblog.com/2014/01/16/compiling-lambda-expressions-scala-vs-ja...

в Scala 11 кстати тоже будет такой кодогенератор для лямбд, только пока в качестве экспериментальной опции

Guava Optional

Java SE 8

Что там с Sumatra и OpenCL/HSA?

В язык Java добавлена поддержка лямбда-функций

Блин. Секта K&R, похоже, осталась в гордом одиночестве.

Жрать-то хоть меньше стал?

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

зы. семантика замечательная забава.

Добавили. Гугли type annotations.

однако в этом случае замыкания ограничины константными состояними не так ли?

из лямбды не осторожно менять переменые которые оказались доступные по разным путям (из лямбды и из исходного окружения в котором осталось указание на захваченое лямбдой)

если же только лямбда владеет состоянением(которое читает и если надо меняет) - то это и есть годное замыкание без вопросов и уточнений.

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

однако в этом случае замыкания ограничины константными состояними не так ли?

не совсем - замыкание позволяет работать со свойствами объекта, и локальными переменными. поскольку замыкание потенциально связывает разные потоки (поток функции и поток лямбды), то сделана защита локальных переменных от race-condition.

Если нужно обойти защиту ЛОКАЛЬНЫХ переменных функции, то стоит проверить а нет ли нарушения тех или иных подходов и best practices. По простому - а не «овнокод» ли требует доступа к локальным переменным. Скорее всего есть грамотный путь - streaming API / reduce / etc.

PS лямдбы - реализация функционального подхода. а ФП не всегда имеет состояние. Чаще stateless.

Никлаус Вирт тоже не любит лямбды.

где это он прямо так вот утверждал/утверждает?

ежель он в Обероне вполне приемлет сборку мусора

ну а стековоя организация функций(включая возможность вложенности функций унаследованая из Паскаля унаследованая из Алгола ) в сочетании со сборкой мусора и выделением локальной памяти не через стек , а через хип(т.е возможность возврата памяти системе не только через FILO а как угодно) автоматом приводит к замыканиям.

так всё таки нынешнии замыкания в Жаве позволяют быть полноценым poor-man object али только poor-man value?

Понятно, то есть лямбды осилили, а замыкания нет.

Но хоть сахарок, чем по 5 строк писать на каждую лямбду...

можно поподробнее про арифметику?

ну ты умный.... Процессор обнови, ну или хотябы подожди пока Ноч обновит код до 8ки, там посмотрим что будет)

NullPointerExceptions |

Это 99% ошибка разработчика, жаба не виновата))))))

жаба не виновата

в нормальных языках компилятор такое даже не скомпилирует.

а через косвенность это решается?

или и разименованная сущность тоже обязана быть 'effectively final' ?

http://docs.oracle.com/javase/8/docs/technotes/guides/lang/enhancements.html#...

См. раздел «Unsigned Arithmetic Support».

Ну, с паттерн-матчингом да, не особо. А вот Optional в stream api вполне себе появился, что частично от npe избавляет.

Нужно!

Очень круто!
Жаль только, что на работе еще только шестая версия используется :(

У меня 6-ядреный Phenom, он до сир пор рвёт топовые Athlon последних лет. Потому что ядра настоящие физические, а не гипертрейдинг.

прошу прощение, писал ночью.

*API

slf4j решает задачи логирования удобным образом. Если нужно что-то еще, то log4j / logback / Java logging в помощь.

Вы наверное не в теме, раз так рассуждаете. Речь не об этом. А о нормальной поддержки API логирования на уровне Java. То что есть сейчас назвать жалким подобием, язык не поворачивается. А библиотеки есть, не спорю. На любой вкус и цвет.

На уровне языка и платформы самые вкусные изменения - лямбда и модульность.

Никогда не страдал подобное фигней. Не считаю это чем-то важным.

Лямбду сделали, модульность к сожалению все пилят.

То есть без модульности никак? Скажу более это то, без чего можно обойтись.