Здравствуйте, vsb, Вы писали:

vsb>Дурость, натуральная.
vsb>Во-первых никакой необходимости в этом всём вообще нет. Заменяем int x на int[] x = new int[1], все обращения к x на x[0] и готово, у нас с абсолютно тривиальным преобразованием работает изменение переменной из замыкания.
Необходимость не техническая, а семантическая. Чтобы по коду было интуитивно понятно что происходит. Замена значения на стеке полем в объекте — имеет конкретные последствия и работает единообразно для всего, никаких особых случаев для лямбд нет.

vsb>Во-вторых, даже если разработчики Java с чего-то решили, что теперь их миссия — zero overhead abstractions (ха-ха) и превращать под капотом переменную в массив это не ок, то никакой проблемы написать final у нужной переменной нет и это как раз уменьшает WTF/LoC. Т.е. необходимости ввода effectively final концепции не было никакой. Нужна тебе final переменная — ну и напиши final. Это как вводить effectively int концепцию — если не указали у переменной тип, то она будет считаться int-ом. Зачем? Какую проблему решает? Непонятно.
effectively final — небольшой сахарок, позволяющий выводить final автоматически во время компиляции и возможность его не писать его явно. В каком-то смысле аналог var.

>> В шарпе и js с этим налажали и там это классическая грабля.
vsb>Это вообще другая проблема и эту проблему так же легко исправить.
Проблема в том, что неоднозначно что в какой момент должно меняться. Поэтому явное требование финальности — заставляет писать код, в котором всё становится явным.

vsb>В Go, кстати, исправили в одной из последних версий.
Любопытно, как?