maytonНовые концепции мультипоточности нужны. Насколько я понимаю сейчас идет их активное переосмысление.
У вас есть примеры? Чего вам надо?

cossack5С другой стороны, лямбды в джаве - это кривая нашлепка
Вы пол-процента своего кода цените выше 99.5 оставшегося?
cossack51) замыканий нет
Ну ведь врёте же. Финальные переменные доступны. Финальные переменные с состоянием модифицируемы.
cossack52) лямды нельзя вызывать как методы, т.е. lamdba() вместо lambda.run()
Лямбды изначально одноразовые изделия. И делать из них "много раз" - ну извращайтесь, конечно, но другим так не советую.
cossack53) inference типа лямбды, т.е. для лямбды обязательно нужно определить интерфейс (либо взять стандартный Consumer, Runnable, Predicate и т.д.), т.е. callLambda(Consumer<Foo> foo) вместо callLambda( int-> void fun) (приблизительно).
Опять вы за многоразовость. Лямбду вызывают неявно там, куда её отдают. А явно что-то делать с чем-то даже названия не имеющим - бред.

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

У вас голова способна переварить хотя бы пяток одновременных мыслей? А всё туда же, дайте мне, не знаю зачем, но дать должны!
cossack5Тоже самое и с остальными пунктами.
Вот-вот. По остальным - то же самое.
cossack5а use case'ов полно.
Покажите же. Чего там полно, ну и работоспособно ли вообще. А то как-то подозрительно скромничаете.

maytonПока ключевое слово Project Loom.
Поглядел.

Сначала гордо заявляют:
авторthe implementation of the software unit of concurrency in Java — the thread — is insufficient
Потом набрасывают мега-бонусы:
авторFibers are much more lightweight than kernel threads in terms of memory footprint, and the overhead of task-switching among them is close to zero. Millions of fibers can be spawned in a single JVM instance, and programmers need not hesitate to issue synchronous, blocking calls, as blocking will be virtually free.
И не стесняясь добавляют:
авторSimplicity will come with no tradeoff.

А вот потом, эдак между делом, вставляют такое:
авторIn general, the fiber API will be nearly identical to that of Thread

И где здесь хвалёная Simplicity?

В целом перцы пока лишь мечтают. Заявляют в будущем времени и разного рода "мы хотим".

Сама идея наваять шедулер внутри и на Java может быть интересной с точки зрения хакерства (понимания, как оно работает), но про полезный выхлоп пока что видим лишь громкие заявления про Simplicity, которая даётся как бы даром (no tradeoff).

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

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

maytonНу тема достойна отдельного топика.

Как вы считаете?
Вы же вроде даже в одном сообщении не смогли сказать более пары строк. Вы уверены, что действительно нужна тема?

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


... Опустим разговоры про bad design и все такое.

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

Но если не опускать, то сразу возникает вопрос - а что конкретно выведет данная программа в консоль? Напишите ваш ответ, а я потом покажу, что на самом деле всё будет не так, как вы написали.
cossack5Что касается, пункта 2, вызов метода выглядит чище (lambda()) нежели вызов объекта lambda.run(). Чище и красивее.
Выглядит короче и некоторым кажется, что это как раз то, что им нужно. Но эти некоторые, конечно же, совсем забыли про все остальные случаи использования лямбд.

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

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

В общем вижу типичное выхватывание понравившихся кусков, сопровождаемое непониманием взаимосвязей между выхватываемым и остальным. Всё остальное просто перестанет работать, если вот так вот по детски заявлять "я хочу run() вместо У.run()". Потому что кроме одного единственного случая в мире существует много других, про которые тоже нужно думать.
cossack5По третьему пункту, в скале лямбды без интерфейса удобная вещь, т.к., нет необходимости создавать интерфейс внутри лямбды или запоминать стандартные (зачем мне знать про все эти BiFunction,BiConsumer,BiPredicate и т.д.).
Когда-то давно в Java умные дяди устранили массу причин для возникновения ошибок, например - указатели. В том числе - указатели на функции. Но подрастающее поколение не ценит достижений предков. И хочет опять получить указатели. Но с ними - все классы ошибок, от которых умные дяди избавили подрастающее поколение.

Если вы хотите получить удовольствие от вылавливания проблем с указателями - пишите на сях, там вам этого добра будет доступно по самое верхнее место. Но зачем весь это геморой тянуть в Java? Ну а если уж очень хочется, то в Java реализован безопасный подход, не влекущий за собой весь упомянутый сонм ошибок. Но подрастающее поколение хочет всё и сразу! Ну ладно, я не против, только предложите плиз вариант, когда и ваши хотелки реализованы и куча ошибок не полезла.