·>Лямбды тут непричём. Вообще.
·>wiring код немного поменяются. И собственно всё. Вся бизнес-логика остаётся как есть, и можно масштабировать старинный код, который все боятся трогать.

Можно и без лямбд, но Runnable/Callable при создании VirtualThread передать придется.

m>>(а если ещё вспомнить, что лямбды в Java не умеют захватывать неконстантные переменные в отличие от C#)
·>Шо?! Они переменные со стека не умеют захватывать только. Как собственно и в шарпе.

Разницу C# и Java применительно к захвату переменных лямбдами обсуждали тут: Класс для возврата значения из лямбды
Мне для получения результата Callable, обернутого в VirtualThread, придется к таким же ухищрениям прибегать, как в той теме?

m>> Из статьи на которую ссылается TC, преимущество перед async/await неочевидно (там сравнение с async/await в Котлине)
m>> (https://blog.rockthejvm.com/ultimate-guide-to-java-virtual-threads/)
·>С тем, что код тупой, обычный, синхронный, понятный любому индусу, без всякого мусора async/await, возможно написанный ещё до создания самого c#. Гугли "function coloring".

Ты утверждал, что код остается "плоским", однако из примеров в статье видно, что вложенность увеличивается

static Thread bathTime() {
  return virtualThread(
    "Bath time",
    () -> {
      log("I'm going to take a bath");
      sleep(Duration.ofMillis(500L));
      log("I'm done with the bath");
    });
}

И что насчет перехвата исключений? Перехватывать нужно внутри VirtualThread?