Что является общими неопределенными поведениями, о которых должны знать Программисты Java

Существует очень, очень мало неопределенного поведения в Java, по сравнению с C/C++, это - намного более четко определенная платформа. Причина этого состоит в том, что компиляторы C/C++ предназначены для создания кода для совсем других платформ и поэтому были предоставлены довольно широкие свободы для предотвращения слишком строгих требований, которые вынудят компилятор произвести субоптимальный код для данной платформы.

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

основной областью, где неопределенное поведение происходит, является точная синхронизация и планирование нескольких потоков (как Tom Hawtin, уже упомянутый)..

существует несколько мест, где поведение не очевидно, 'хотя, таким образом, это могло бы выглядеть неопределенным, но не (примеры Сравнения строк, данные Oscar Reyes, яркий пример).

И несколько мест, где поведение определяется, чтобы быть неопределенным (например, порядок элементов в HashMap определяется, чтобы быть зависящим от реализации и не должен быть постоянным).

Я думаю что Java(TM) Puzzlers: Прерывания, Ловушки и Угловые Случаи книга будет очень полезна, она объясняет много скрытых идей и неопределенных поведений Java.

Сериализация . Это не не определено, по сути (существует детерминированный алгоритм). Однако для случайного наблюдателя нисколько не очевидно, что будет или не вызывать изменение в serialVersionUID, таким образом мешая всем Вашим попыткам использовать RMI, JMS и множество других акронимов.

Так, это обычно - хорошая идея , рассматривают Ваши возможности , когда Вы знаете, что необходимо будет сериализировать объект. Я особенно люблю, "всегда включают его как поле" техника:

private static final long serialVersionUID = 1L;

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

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

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

кроме того, Object.clone () имеет некоторые основные проблемы, и его использованию препятствуют в большинстве случаев. Посмотрите Объект 11 от "Эффективного Java" Joshua Bloch для полного ответа.

Четко определенный, но не очевидный:

Объектный тест для равенства:

== используется для тестирования ссылок (сделайте эти две ссылки на объект точка к тому же объекту)

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

Так, например

new String("test") == new String("test")  

ложь, в то время как

new String("test").equals( new String("test") )

верен

, Строковые объекты интернируются так, следующее возвращает 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 с scriplets, и новые программисты не добираются, почему проверки

 <%if( param == "continue" ) { %>

Никогда не происходит

Одна вещь, которую я помню, расценивает jvm совместимость с jni. Мы имели и приложение, которое было разработано на jdk1.4 и при установке его на машине с IBM jvm (jikes, я верю), вызов jni просто рвал! Это было в 2006 все же. Я полагаю, что это имеет мало общего с Java как с языком, но больше сделать с Java как платформа.

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

Не неопределенный, но неожиданное поведение то, как удваивается, округлены, когда преобразовано в целое число. 0.6d всегда округляет в меньшую сторону до 0; на самом деле 0.9d также округляет в меньшую сторону до 0. Но 0.99999999999999995 и больше окружит к 1.

Просто интересное поведение при кастинге результатов Math.random () звонят в beaware.