То же, что и этот вопрос, но для java
Обновление Основываясь на комментариях и ответах нескольких людей, ясно, что Java имеет очень мало поведения undefined.
Поэтому я хотел бы спросить, какое поведение не очевидно. Пожалуйста, при ответе сделайте различие между ними:)
Все, что связано с потоками...:)
также:
В Java существует очень малое поведение undefined, по сравнению с C/С++, это гораздо более четко определенная платформа. Причиной этого является то, что компиляторы C/С++ предназначены для создания кода для очень разных платформ и поэтому получили довольно широкие свободы, чтобы предотвратить слишком строгие требования, которые заставили бы компилятор создавать субоптимальный код для данной платформы.
Java пожертвовала некоторыми из них, определяя почти каждое поведение очень точным способом и допуская только небольшие степени свободы. Это, конечно же, упрощает обработку платформы.Основная область, в которой происходит поведение undefined, - это точное время и планирование нескольких потоков (как уже упоминал Том Хоутин).
Есть несколько мест, где поведение не является очевидным ", хотя он может выглядеть undefined, но не является (примеры String, приведенные Оскаром Рейсом, - отличный пример).
И в нескольких местах, где поведение определено как undefined (например, порядок элементов в HashMap определяется как зависящий от реализации и не обязательно постоянный).
Я думаю, что книга Java (TM) Puzzlers: Traps, Pitfalls и Corner Cases будет очень полезна, она объясняет многие скрытые моменты и undefined поведение java.
Сериализация. Это не undefined, само по себе (существует детерминированный алгоритм). Однако для случайного наблюдателя совсем не очевидно, что будет или не вызовет изменения в serialVersionUID, таким образом, лишив всех ваших попыток использовать RMI, JMS и ряд других сокращений.
Таким образом, обычно рекомендуется рассмотреть ваши варианты, когда вы знаете, что вам нужно будет сериализовать объект. Я особенно люблю "всегда включать его как полевую" технику:
private static final long serialVersionUID = 1L;
Измените значение этого поля только тогда, когда разработчик узнает, что произошел сбой для совместимости с вашим кодом. Не позволяйте JDK принять это решение за вас....
Я не совсем уверен, что вы подразумеваете под "undefined behaviors", но, как указывали другие, основной язык очень предсказуем на разных платформах, а также версии языка и JVM.
Это неверно для графики (Swing, AWT), однако, которые, как правило, непредсказуемы и не обязательно воспроизводятся на разных платформах. Я работал над графическим приложением для визуализации на основе Java, и я потратил много времени на то, чтобы "писать один раз и отлаживать всюду".
Кроме того, Object.clone() имеет ряд серьезных проблем, и его использование в большинстве случаев не рекомендуется. Для получения полного ответа см. Пункт 11 "Эффективная Java" Джошуа Блоха.
Есть два поведения undefined, о которых я знаю:
a) Перегрузка метода с помощью параметра, который является подклассом того же параметра в перегруженном методе. Например:
void doSomething(Object obj);
void doSomething(String str);
Невозможно узнать, какой метод будет вызываться в doSomething ( "Hello world!" ), поскольку обе подписи действительны. Кроме того, это поведение может изменяться с VM на VM и даже с выполнения на выполнение.
b) Вызов неконкретного метода того же класса в конструкторе. Поведение undefined происходит, если этот метод переопределяется в подклассе. Обратите внимание, что построение происходит от суперкласса к подклассу. Случай становится особенно неприятным, если метод подкласса использует некоторые локальные атрибуты подкласса. В случае Oracle VM локальные атрибуты будут построены, конструктор суперкласса завершит выполнение, тогда, когда достигается конструктор подкласса, атрибуты будут построены снова, переопределяя ранее определенные значения.
Объектный тест для равенства:
== используется для проверки ссылок (эти две ссылки на объекты указывают на один и тот же объект)
В то время как equals используется для проверки равенства объектов.
Итак, например
new String("test") == new String("test")
Является ложным, а
new String("test").equals( new String("test") )
Является истинным
Объекты String интернированы, поэтому следующее возвращает true:
String a = "test";
String b = "test";
a == b // returns true
НО, если строка создается где-то в другом месте (например, из базы данных)
String a = "test";
String b = getFromDataBase(); // internally the remote returns "test"
a == b // returns false.
Валидация ложна.
Я видел это в jsp со скриптами, и новые программисты не понимают, почему валидация
<%if( param == "continue" ) { %>
Никогда не бывает
Одна вещь, которую я помню, касается совместимости jvm с jni. У нас было и приложение, которое было разработано на jdk1.4, и при установке его на машине с ibm jvm (как я полагаю, jikes), jni-вызов просто потупился! Это было в 2006 году. Я считаю, что это мало связано с Java как языком, но больше связано с Java как платформой.
Добавить динамическое и статическое связывание и как оно применяется к перегруженным и переопределенным методам как не очевидно.
Не undefined, но неожиданным поведением является то, как удваивается округление при преобразовании в целое число. 0.6d всегда округляется до 0; на самом деле 0.9d также округляется до 0. Но 0.99999999999999995 и больше округляется до 1.
Просто интересное поведение при выдаче результатов вызова Math.random() для beaware of.