#java #final
Без всяких лишних слов напишу код:
public class A {
static Object f() {
String str = "hello";
str = "world"; // (1) ошибка компиляции!
class X extends Object {
public String toString() {
return str;
}
}
return new X();
}
static Object g() {
String[] s = { "hello", "silence" };
s[0] = "World"; // (2) НЕТ ошибки компиляции.
class X extends Object{
public String toString() {
return s[0];
}
}
return new X();
}
public static void main(String[] args) {
}
}
Закомментирование строки (1) даст компилятору понять, что str в f() есть effectively
final, код скомпилируется.
Закомментирование строки (2) не нужно. Ведь s -- ссылка на массив, которая не изменяется.
Взятие s[0] затем законно.
Вопрос: Зачем от нас требую использование только final или effectively final локальных
переменных в локальном классе? Я могу работать с первой ячейкой массива s и всё у меня
будет замечательно.
Мои мысли и непонятки: как вообще будет выглядеть код объекта класса f().X ? Это
будет объект с кодом из Object, но его метод toString() будет таким (псевдокод):
public String toString() {
return 0x47e9c2dd;
}
Где, как понимаю, 0x47e9c2dd адрес той самой строки str? Но если бы оно работало
так, то какая разница какой адрес мы бы положили в этот метод, когда создавали экземпляр
класса f().X ...
Так же не понимаю: мы определяем метод toString() класса f().X ссылаясь на локальную
переменную str, которая (как ссылка) исчезнет по завершению работы f(), но при том
объект возвращённый из f() содержит в своём toString() ссылку на str (как объект).
Значит у нас тратится RAM на то, чтобы держать метод f().X.toString() определённым?....
В общем я очень запутался, совершенно не понимаю происходящего с этими локальными
классами в том свете, что на нас возложено это странное требование на final или effectively
final. Объясните происходящее, пожалуйста...
Ответы
Ответ 1
В Java замыкания захватывают значения, а не переменные. При компиляции внутреннего
класса, Java создаст в нём поле для хранения значения переменной, "захваченной" из
внешней области видимости:
$ javac A.java
$ javap A$1X
Compiled from "A.java"
class A$1X {
final java.lang.String val$str; // <-- "hello"
A$1X();
public java.lang.String toString();
}
У требования к неизменяемости обеих переменных есть несколько причин.
Уверен, самым главным было то, что Java позиционируется как язык, в корне пресекающий
возможность совершения множества ошибок и вынуждающий программистов писать правильный
код. А классические замыкания - это не самая простая и интуитивно понятная тема. Поэтому
в Java замыкания сознательно ограничили и сделали более простыми.
Кроме того, если реализовывать классические замыкания, то необходимо было бы каким-то
образом сохранять захваченную переменную. Например, выделять место в куче. Во-первых,
это потребовало бы доработки виртуальной машины и, возможно, изменения байт-кода. Во-вторых,
это повод для утечек памяти.
Можно было бы сделать поле val$str изменяемым, но это усложнило бы и замедлило использование
анонимных классов и лямбда-выражений в многопоточной среде. Можно было бы дать программисту
возможность выбирать, когда это поле финальное, а когда нет, но тогда оно перестаёт
быть неявным и мы опять приходит к необходимости доработки виртуальной машины, усложнению
языка и поводам для ошибок.
Можно было бы не ограничивать изменяемость переменной из внешней области видимости,
но на уровне языка переменная str одна, вероятность того, что в разных областях видимости
она может иметь разные значения - это ещё больший повод для ошибок, чем классические
замыкания.
Подытоживая, ограничение на неизменяемость переменных одновременно сделало и язык
лучше, и техническую реализацию замыканий проще.
Кое-что об этом можно почитать у Брайана Гетца в "State of the Lambda: Variable capture".
