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

VD>final — это совсем из другой оперы. Это запрет на переопределение. Аналог в C#/Nemerle — sealed.

VD>Помешать ошибке в описанных мной случаях это не может.

Однако не понятно, как такие ошибки влияют на безопасность?

VD>>>5. Присвоение вместо сравнения. Как и в С++ эти грабли присуствуют в Ява.

E>>?
E>>Не понял.

VD>Что там понимать:
VD>

VD>while (variable = 1)
VD>    ...
VD>

VD>вместо
VD>

VD>while (variable == 1)
VD>    ...
VD>

VD>и приплызд. Хотя конечно это могли быть проблемы компилятора который у меня тогда был.

Очень вероятно:

class Test {
    public void test_assigment_in_condition() {
        int var = 0;
        if( var = 1 )
            System.out.println( "failure (var = 1)!" );
    }
}

результат:

Test.java:4: incompatible types
found   : int
required: boolean
                if( var = 1 )
                        ^
1 error

Так что мимо кассы. Подобная проблема будет существовать только, если var имеет тип boolean.

E>>Никто не подскажет программисту убрать однажды написанный ignore.

VD>Я вообще не понял, что ты пытался сказать. Зачем что-то убирать? Или ты явно выражашь намерение проигнорировать результат, или ты используешь результат. В обратном случае получаешь сообщение компилятора. Таким образом ты физически не можешь проигнорировать значение функции по невнимательности.

Я хочу сказать, что во многих случаях придется писать ignore. Например, когда объект возвращает ссылку на самого себя для того, чтобы можно было выстраивать цепочку действий. Вот аналоги из C++:

std::cout << "total time: " << (start - finish) << " msec" << std::endl;

Md5_Hash hash;
hash.put( "Message: " ).put( message_id ).put( ", content length: " ).put( content_length );

Программист вынужден будет в этих случаях писать ignore. Геморрой на ровном месте.

VD>Ошибка — эта очень частая.

May be. Тем не менее к безопасности это вряд ли имеет отношение. Катострофических последствий это не вызовет, поскольку это логическая ошибка программиста. С таким же успехом программист может поставить ignore там, где ему нужно было сохранить значение. Запись:

ignore( str1.Replace( "some", "other" ) );

остается синтаксически валидной, но вот смысла в ней совершенно нет.

E>>А как же наличие спецификаций исключений в Java? Аналог в Nemerle есть?

VD>Это к граблям не приводит.

Да уж. Потерянные исключения -- это не грабли.

Итого получается: реально исправленные проблемы с ==/equals, гипотетическое преимущество в switch/case и такое же гипотетическое преимущество (ли?) по поводу возвращаемого значения. И минус спецификация исключений. Не густо для языка, появившегося на 10 лет позже Java.