Явское ключевое слово 'финала' на самом деле улучшает безопасность?

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

Что обычно подразумевается под «безопасностью» в таких видах дискуссий, является концепция модели безопасного объекта - то есть объектная модель, которая не может быть манипулирована потребителями для целей, непредвязанных оригинальным автором класса.

Безопасно против чего?

с точки зрения мобильного кода (код, который может перемещаться между системами - апплетами, Midlets, Webstart, RMI / Jini и etc), очень важно. Применяется к классам, и в меньшей степени доступные методы, это предотвращает вредоносные реализации. Точно так же с доступными полями, заметной статики. Если вы собираетесь написать код, который может стать частью библиотеки, вы должны быть остовырены об этом.

Для типичных, скажем, Web или Desktop код приложения, он гораздо менее важен. Тем не менее, его отсутствие на полях делает код более сложным для чтения и указывает на запутанный программист. Такой код вряд ли будет безопасен только потому, что он плохо написан.

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

Однако, если вы управляете JVM, процесс работает на (скажем, вы запускаете код, предоставленный другими на вашем JVM), то окончательное и частное действительно обеспечивают безопасность, связанные с SecurityManager Java. Вещи, которые вы можете сделать, через отражение, чтобы обойти эти ограничения, можно предотвратить.

То, что вы не можете сделать, - это код судов, чтобы запустить на чужой JVM и думать, что вы ничего не скрываете.

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

Вы должны каким-то образом проверить тип, если это последовательность или кортеж. Я бы сделал это так:

keywords = library.get_keywords()
if not isinstance(keywords, tuple):
    keywords = (keywords,) # Note the comma
for keyword in keywords:
    do_your_thang(keyword)

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

Под «безопасностью» обычно понимается концепция защищенной объектной модели, то есть объектной модели, которой потребители не могут манипулировать в целях, непреднамеренных первоначальным автором класса.

Речь идет скорее об «изменении» материала, а не «обеспечении безопасности». Последние ключевые слова просто лишают возможности изменять/изменять/расширять любой метод.

Финал также повышает производительность / управление памятью.

Ключевое слово «Final» действительно имеет некоторые последствия безопасности. Представьте себе, что вы проектируете безопасную систему, которая имеет службу, которая, данная строка, делает что-то, если и только если строка действительна. Вы можете написать:

public void doSomethingUseful(String argument) {
    checkValidity(argument);
    /* prepare to do something useful... preparation takes a bit of time! */
    reallyDoTheUsefulTask(argument);
}

Если строка не была окончательной, некоторые умные злоумышленники могут подклассьте строку. Их строка не является неизменной, как класс Stock String - и на самом деле они могут создавать другую нить и пытаться делать атаки на ваш метод, изменив аргумент после проверки контрольной связи, но прежде чем на самом деле использовать аргумент. Тогда ваша «полезная задача» внезапно делает что-то совершенно неправильное, возможно, ущерб безопасности. Они только что обошли ваши чеки! Потому что Java.lang.String является окончательным, однако, у вас есть хорошие гарантии, что когда вы просите строковый параметр, это, на самом деле, стандартная неизменная строка. Это довольно большое дело - был весь класс атак в режиме ядра на основе неправильного обращения параметров с помощью SESCalls.

Так да, финал может иметь некоторые соображения безопасности.

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

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

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

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

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

Это поведение позволяет рассуждать о состоянии объекта и сделать определенные допущения, когда несколько потоков доступны одновременно.

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