Будет ли async await в Java?

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

А вот в виде библиотечных конструкций - пожалуйста. В комментах упомянули CompletableFuture могу добавить еще ea-async.

Собственно, таков путь (с) Мандалорец - Java берет стабильным синтаксисом и богатством библиотек, в отличие от .NET, который непрерывно пихает в свой синтаксис что ни попадя...

Update

Дополню свой ответ философскими размышлениями.

1. В основе Java лежат несколько краеугольных камней: ООП, write-once, networking, security и строгость + простота. Если посмотреть на историю вопроса, то Java возникла как ответ на сложность и неуниверсальнось С++ (как бывший С++ девелопер, я когда переходил на Java был покорен именно простотой языка). Я крайне ценю то что архитекторы языка до сих пор подвержены этой философии и крайне неохотно идут на расширения синтаксиса языка и то только для простоты. Те же лямбды появились только потому, что они упрощают синтаксис.

2. Если убрать из философии Java строгость - мы получим Kotlin, где простота доведена до предела (кое-где естественно в ущерб строгости) и видя конструкцию типа:

   val myValue = superPuperClassObject.getSomething()

ты не понимаешь какой же тип возвращает это метод?! Ситуация в принципе немыслимая для Java в Kotlin доведена до предельного состояния и используется как способ сокращения издержек на программирование.

3. Теперь собственно к истории с async-await. Нет и не будет никогда async-await в Java как элементов синтаксиса - по причине указанной в п.1 - это разрушает концепцию простоты, это фактически будет расщеплять код на синхронный и асинхронный. По сути Java динозавр предназначенный для синхронного программирования и таковым останется, вся асинхронность вынесена в библиотеки.
4. .NET равно как и JS не имеют своей концепции - они в общем то развиваются достаточно хаотично и спонтанно, по принципу: понравилась - берем в язык. Что в общем то не умаляет их достоинств, безусловно.

Вот что я нашел на просторах SO (свободный перевод)

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

Согласно докладу Рона Пресслера, асинхронное программирование с использованием CompletableFuture вызывает три основные проблемы.

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

2. нельзя использовать stacktraces для выявления источника ошибок, профилирование становится невозможным

3. это вирусно: все методы, которые выполняют асинхронные вызовы, также должны быть асинхронными, т.е. синхронный и асинхронный миры не смешиваются

Хотя async / await решает первую проблему, он может только частично решить вторую проблему и не решает вообще третью проблему (например, все методы в C #, выполняющие awit, должны быть помечены как async).

Но зачем вообще нужно асинхронное программирование? Только для предотвращения блокировки потоков. Таким образом, вместо того, чтобы вводить async / await в Java, в проекте Loom Java-дизайнеры работают над волокнами (fibers) (также известными как легкие потоки), которые будут стремиться значительно снизить стоимость потоков и тем самым устранить необходимость в асинхронном программировании. Это сделало бы все три вышеупомянутые проблемы также устаревшими.

PS. Складывается впечатление что разработчики C# и JS отталкиваются от других принципов.

Да вроде бы достаточно возможностей:

1. Вручную Wait-Notify для нескольких потоков.
2. CompletableFuture.allOf().
3. Реактивный Mono.zip().