@NewBi

Добрый вечер. Объясните пожалуйста, почему в локальном классе могут использоваться только финальные переменные или переменные которые были инициализированы при объявлении (effectively final). Почему в локальном классе нельзя использовать обычные переменные, т.е. изменяемые ??

Спасибо !!!

0

@xoraxax

https://docs.oracle.com/javase... asses.html

1

@Lumber

Это относится только к переменным объявленным вне локального класса.

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

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

1

@NewBi

xoraxax, т.е. локальный класс захватывает переменную, а почему он не делает копию этой переменной ? или
внутреннюю скрытую ссылку на эту переменную ? (что-то вроде лямда-функции в C++11, которая может захватить переменную по ссылке или по значению).
И все же непонятно, почему локальный класс не может захватить эту переменную после какого-нибудь изменения, т.е. почему должна быть именно effectively final?

0

@Lumber

Локальный класс именно делает копию с захватываемой переменной.
А запрет на её изменение искусственный, и не имеет "технической необходимости". Зачем он введён - я своё предположение написал выше.

Захват ссылки на локальную переменную я сомневаюсь что можно сделать в Java. Она же в стеке находится и исчезнет когда метод завершится. А ссылка останется, и что будет? Во-вторых в Java вообще нет ссылок на стек.

0

@LeX

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

То что переменная должна быть final или effectively final как раз таки техническое ограничение. Переменная захватывается по ссылке, а примитив соответственно по значению. Это делается для того что бы метод и локальный класс оперировали одним и тем же значением. При этом то что объект в стеке не мешает использовать его в локальном классе, ссылка и есть ссылка, а объект соберется коллектором потом, когда на него перестанут ссылаться.

0

@Lumber

В java не может быть объектов в стеке. И сборщик мусора в стеке ничего не убирает. В стеке только примитивы и ссылки.
Захват ссылки на объект не есть захват объекта.

(В C++ могут быть объекты на стеке и указатели/ссылки на стековые переменные в том числе и примитивные типы, кроме того в C++ в отличии от Java допустима ситуация когда указатель невалиден так что там захват можно организовать по другому)

Термин "захватывание" относится только к локальным переменным. А ссылок на локальные переменные в Java не существует в принципе. Захватывается всё по значению.

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

Фактически значения переменных захватываются в момент создания экземпляра локального класса.
(можно считать что захватываемые переменные передаются неявно как аргументы в конструктор локального
класса и записываются в его поля).

Но чтобы об этом не приходилось думать просто запретили менять переменные.

0

@LeX

Ваш кэп. Я имел ввиду ссылку


парень, в java все по ссылке.


Lumber, вот тебе must read для освежения знаний. метод имеет внутри себя переменные, которые имеют значения (примитивы) либо ссылки (на объекты). локальные классы, так же как анонимные классы и лямбды, захватывают локальные переменные по ссылке либо по значению для примитивов, т.е. копируют ссылку или значение. в случае с полями родительского класса происходит захват ссылки на экземпляр родительского класса (обращение как ParentClass.this.member), поэтому поля менять можно, а в случае метода нельзя, т.к. у метода нет ссылки и соответственно обратиться как methodName.member нельзя. то же самое касается переменных метода родительского класса

Добавлено через 57 секунд
NewBi, тоже обрати внимание на написанное

1

@xoraxax

http://csharpindepth.com/Artic... sures.aspx

0

@LeX

0

@Lumber

а ссылка захватывается по значению

Захват по ссылке привёл бы к возможности изменять захватываемые переменные. Чего нет.

Собственно ради людей которые этого не понимают и путают ссылку на объект с самим объектом, а захват ссылки с "захватом по ссылке" и было введено требование неизменяемости захватываемых переменных.

1

@LeX

а я что написал?

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

тебе самому надо со всем этим разобраться

1

@Lumber

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

0

@LeX

кэп, а я о чем говорю?

0

@NewBi

Можно же захватить как read-only. Вот например в C++, лямбда функция может захватить переменную по значению, но тогда эту переменную менять нельзя, можно просто использовать значение этой переменной в теле лямбды.
Вот пример:

Т.е. "a" является переменной не effectively final, и спокойно происходит ее захват.
Я не понимаю вот этой необходимости в effectively final переменной. Почему не может работать как в первом примере?

0

@Lumber

Да, даже можно было бы и не read-only сделать. Это тоже искусственное ограничение в C++.

Это просто две разные переменные с одинаковыми именами, которые ничто не мешает (кроме правил языка) менять независимо.

0

@LeX

раз это так и ты знаешь как сделать - реши проблему и создай пул реквест в java, опенсорс все-таки.
ну и в комюнити c++ можешь еще рассказать как реализовать, поучить людей так сказать) а то сидят тупые, сделать не могут)

0

@Lumber

Это вопрос не реализации, а стандарта языка.

0

@LeX

Ну ок, стань участником JCP сначала)

0

@Belyak83

Область видимости локальных переменных в джаве это метод, конструктор или блок в котором объявлена эта переменная (+ их внутрянки).
Спецификация языка гарантирует, что эти переменные не могут изменять вне области видимости.
Блок может "помереть", а локальный класс, объявленный в этом блоке, можно передать еще кому-нибудь. Поэтому значения этих переменных "прошиваются" в этом классе во время его объявления.
Чтобы поддерживать спецификацию (нельзя изменять вне блока) и как-бы "имитировать" что в локальном классе и в блоке одна и таже переменная - эти локальные переменные должны не изменяться - быть финал или эффективити финал.
Чтобы в этих переменных был какой-нибудь смысл они должны быть инициализированы до создания локального класса.

0