Ответ 1
Вы можете написать детерминированную программу на Java. Вам просто нужно устранить возможные источники недетерминированности.
Трудно понять, что может быть причиной недетерминированности, не видя вашего фактического кода и конкретных доказательств этого детерминизма.
Существует множество методов библиотеки, которые потенциально могут быть источниками недетерминированного поведения... в зависимости от того, как вы их используете.
Например, значение, возвращаемое Object.hashcode()
(при первом вызове экземпляра), не является детерминированным. И это просачивается в любую библиотеку, которая использует хеширование. Это может определенно повлиять на порядок, в котором элементы HashSet
или HashMap
возвращаются, когда вы их итерации... если класс элемента не переопределяет hashcode()
.
Генераторы случайных чисел могут быть или не быть детерминированными. Если они являются псевдослучайными, и они инициализируются фиксированными семенами, то последовательность чисел, создаваемая каждой из них, будет детерминированной.
Арифметика с плавающей точкой должна быть детерминированной. Для любого (фиксированного) набора входов для арифметического выражения результат всегда должен быть одинаковым. (Я не уверен, что детерминизм арифметики с плавающей запятой гарантирован JLS, но было бы странно странно, если бы это произошло на практике. Как и в... вы работаете на сломанном оборудовании.)
FOLLOWUP... на strictfp
и недетерминированности.
В соответствии с JLS 15.4:
"В выражении, которое не является FP-строгим, предоставляется некоторая свобода реализации для использования расширенного диапазона экспонентов для представления промежуточных результатов, а чистый эффект, грубо говоря, заключается в том, что расчет может привести к" правильному ответу ", в ситуациях, когда исключительное использование установленного значения с плавающей запятой или двойного значения может привести к переполнению или недопущению."
Это точно не говорит о том, насколько "свобода" реализации имеет строгие выражения, отличные от FP. Однако я бы подумал, что эта свобода не будет распространяться на возможность детерминированного поведения. Я бы подумал, что компилятор JIT на конкретной платформе всегда будет генерировать эквивалентный собственный код для одного и того же выражения, и этот код будет детерминированным. (Я не вижу никакой причины для недетерминированности... если только аппаратное обеспечение не имеет детерминированной точки с плавающей точкой.) Другим возможным источником недетерминизма может быть то, что поведение JIT-компилируемого и интерпретируемого кода может быть другим. Но, честно говоря, я думаю, что это было бы "орехом", чтобы это произошло... и я думаю, мы бы об этом слышали.
Таким образом, хотя оценка не-FP-строгой оценки может быть недетерминированной в теории, я думаю, что мы должны упустить это... если нет четких доказательств того, что это происходит на практике.
(Обратите внимание, что я говорю о реальном недетерминизме, а не о различиях в платформе.)