Valentin Kolesnikov,

Ну если каждый добавленный в jdk метод и класс считать за фичу, то таки наберется 90 штук. Обычный java девелопер ничего там для себя не найдет. Вот когда добавят operator overloading, async support, value types, string interpolation тогда можно о чем-то будет говорить.

Герой дня,

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

HettТак смотришь на такую лямбду и не понимаешь, с чем вообще дело имеешь.
Попробуйте обычный scala код почитать, он на 99% состоит из лямбд, вот уж где не понимаешь, с чем дело имеешь. Вроде хотел Мартин сделать лаконичный язык, но занесло в другую крайность.
С другой стороны, лямбды в джаве - это кривая нашлепка:
1) замыканий нет
2) лямды нельзя вызывать как методы, т.е. lamdba() вместо lambda.run() - т.я. нужно обременять себя знанием о том, какой метод внутри интерфейса лямбды
3) inference типа лямбды, т.е. для лямбды обязательно нужно определить интерфейс (либо взять стандартный Consumer, Runnable, Predicate и т.д.), т.е. callLambda(Consumer<Foo> foo) вместо callLambda( int-> void fun) (приблизительно). Здесь правде не получится так же красиво как в scala: callLambda(fun: Int=>Unit) из-за того что в джаве тип переменной стоит впереди.

maytonНачиная с OpenJDK-11 строки должны стать экономнее. По крайней мере для latin.
Это вообще вроде в 9-ку ввели. Небольшая фича, а приятно.

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

andreykaT,

Тут Oracle пожалуй переплюнула мелкософт.

alex55555,

Могли сделать доступными и не финальные переменные. Тоже самое и с остальными пунктами.
Бред-не бред, а use case'ов полно. Если вы для себя не видете преимуществ, это не значит, что их нет.

alex55555cossack5Могли сделать доступными и не финальные переменные.
Сьесть-то он сьесть, да только хто-ж ему дасьть?

У вас голова способна переварить хотя бы пяток одновременных мыслей? А всё туда же, дайте мне, не знаю зачем, но дать должны!

В java нельзя написать:


В C#, Kotlin, Scala можно. Опустим разговоры про bad design и все такое.
cossack5Тоже самое и с остальными пунктами.
Вот-вот. По остальным - то же самое.
cossack5а use case'ов полно.
Покажите же. Чего там полно, ну и работоспособно ли вообще. А то как-то подозрительно скромничаете.
Что касается, пункта 2, вызов метода выглядит чище (lambda()) нежели вызов объекта lambda.run(). Чище и красивее.
По третьему пункту, в скале лямбды без интерфейса удобная вещь, т.к., нет необходимости создавать интерфейс внутри лямбды или запоминать стандартные (зачем мне знать про все эти BiFunction,BiConsumer,BiPredicate и т.д.).
В общем, не вижу смысла спорить по этим пунктам. Я свою мысль донес.

alex55555Ну да, если "опустим разговоры", тогда пожалуйста - играйтесь.

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

Здесь зависит:

выведет 0..10, однако в

выведет 10..10, а для foreach цикла это поведение исправили. Немного странно, но не смертельно.
alex55555Выглядит короче и некоторым кажется, что это как раз то, что им нужно. Но эти некоторые, конечно же, совсем забыли про все остальные случаи использования лямбд.

Например - некоторые предполагают, что им на всю жизнь достаточно одного лишь интерфейса Runnable. А я им напоминаю - есть ещё миллионы других интерфейсов. Простой пример - Comparable. И у него один метод - compare(Object x). Но некоторые по прежнему настаивают, что лямбда с Comparable должна выглядеть как lambda.run(). И куда же вставить аргумент? С чем будет сравнивать себя Comparable?

Так вот умные дяди давно поняли, что вызов Х.compare(x) нужно отличать от вызова У.run(). И для того они создали ООП, в котором предусмотрели массу всячески нюансов. А если бы умные дяди не подсуетлись много лет назад, то сегодняшнее подрастающее поколение не смогло бы рассказать, как отличить локальный метод run() от такого же метода объекта У. Ну и до кучи - куда же всё-таки деть аргумент для сравнения?

Что касается Comparable, не вижу большего смысла в его использовании в качестве лямбды (т.к. его предназначение - имплеменить ся классом, который будет поддерживать сравнение). Я не помню, куда можно передать Comparable (мне кажется, никуда), а вот Comparator (lambda.compare(o1, o2)) принимается Collections.sort(), например.
alex55555В общем вижу типичное выхватывание понравившихся кусков, сопровождаемое непониманием взаимосвязей между выхватываемым и остальным. Всё остальное просто перестанет работать, если вот так вот по детски заявлять "я хочу run() вместо У.run()". Потому что кроме одного единственного случая в мире существует много других, про которые тоже нужно думать.

Я вижу косность и ретроградство. Если бы другие люди считали как вы, не появилось бы groovy, scala, kotlin, ceylon и т.д. А Джавой заправляют умные дяди из оракла, которые, не пишут обычный энтерпрайзный код из дня в день, с кучами проверок на null, заведением десятков классов на каждый чих, автогенерацией equals/hascode, геттерами/сеттерами и т.д.
alex55555Когда-то давно в Java умные дяди устранили массу причин для возникновения ошибок, например - указатели. В том числе - указатели на функции. Но подрастающее поколение не ценит достижений предков. И хочет опять получить указатели. Но с ними - все классы ошибок, от которых умные дяди избавили подрастающее поколение.
Не слышал, чтобы кто-то хотел получить указатели. Си - это embedded язык, а в c++ уже 10 лет как никто не использует нативные указатели и ручное управление памятью считается анти-паттероном (если конечно, вы не пишут особый софт). В C# например добавили тип Span<T> для безопасной работы с куском памяти