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> для безопасной работы с куском памяти

maytonalex55555пропущено...

Скорее изменяет. Я не ковырял байт-код восьмёрки, но старое решение в виде дополнительного класса вполне будет работать и в новой среде. Отсюда вопрос - а нахрена козе баян? Зачем разработчикам компилятора ваять какие-то убогие костыли, если старое и так работает?

И да, статичные функции не имеют связи с указателями. Они жёстко привязаны к классу-владельцу. Их нельзя никуда передать. Передать можно лишь описание класса, а дальше синтаксис позволит сделать вызов. И где здесь указатели?
Дружище. Давай возьмем компилляторы линейки 7,8,9,10 и посмотрим какой они собирают код.
С анонимным классом в семерке. И с анонимным классом и лямбдой во всех версиях постарше.
Я спокойно возьму свои слова назад если я неправ.

По поводу боян и костыли. Я думаю что нам с тобой надо внимательно читать Jep-s. Там всегда есть обоснование
этих улучшений. Возможно экономия perm-gen/metaspace что для фреймворков с автоматическими кодо-генераторами может
быть очень даже оправдано.
Драфт находится здесь . Финальный черновик здесь . Тема с method-хендлами нераскрыта.

alex55555Скорее изменяет. Я не ковырял байт-код восьмёрки, но старое решение в виде дополнительного класса вполне будет работать и в новой среде. Отсюда вопрос - а нахрена козе баян? Зачем разработчикам компилятора ваять какие-то убогие костыли, если старое и так работает?

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

alex55555cossack5Вот ведь, разработчики компиляторов, рантаймов, и другие умные дьдяки Оракла, негодяи какие, взяли и наваяли какие-то убогие костыли, и даже не удосужились спросить экспертного мнения alex55555.
Вы по вами представленной ссылке текст читали? Мне очевидно - нет.

Так вот там написано - никаких указателей.

Слушают меня умные дядьки :)
Где я что-то говорил про указатели ? Вообще, то как это реализовано на данный момент, неподвластно вашему пониманию. Указатели или нет. Так что спорить не о чем.

maytoncossack5пропущено...

Драфт находится здесь . Финальный черновик здесь . Тема с method-хендлами нераскрыта.
Эээ... я просто не понял. В первом предложении вы пишете две ссылки. Типа рекомендуете
читать. А дальше - тема не раскрыта. Тоесть читать не стоит? Проясните.
Я имел в виду, не описано как именно работают метод-хендлы (хотя, если учитывать, что они появились раньше лямбд, может и не стоило описать их в статье про лямбды) . А так читать, конечно стоит.

alex55555maytonВ семерке мы могли создать анонимный
класс и определить в нем отдельно getId, и потом создать еще один класс и определить в нем getName и передать их в коллектор.
Кстати - не могли. Ну да это и так будет понятно после наступления понимания.
Почему не могли ?