LINUX.ORG.RU

История изменений

Исправление Legioner, (текущая версия) :

Или в Double или при преобразовании float ставилась запятая как разделитель, если системная локаль русская. Отрыто в какой-то библиотеке для foxpro

Нет такого в toString(). Там всегда точка.

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

Вообще не совсем понятно, откуда у тебя баг, т.к. судя по исходникам всё таки должно работать. Это я не к тому, что equals там стоит использовать, но всё же. Я бы не твоём месте разобрался потщательней, почему у тебя equals не срабатывает.

    public boolean equals(Object obj) {
        return obj instanceof Date && getTime() == ((Date) obj).getTime();
    }

С BigDecimal - это всё понятно, тут ты сам их сравниваешь, делаешь new и всё такое, знаешь откуда они появились.

Не уверен, что тебе тут всё понятно. Суть в том, что в BigDecimal размерность (число цифр после запятой) считаются частью значения при сравнении, поэтому 1.1 == 1.1, но 1.1 != 1.10. Если хочешь сравнивать, как числа, надо использовать compareTo.

Меня это слегка унгетает. Чувствую я в 2к20 они опять уволят ту макау, которая это писала, наймут новую и опять всё перепишут.

Маловероятно. Класс java.util.Date из 1994 года и сделан откровенно плохо. К java.time претензий нет.

Исходная версия Legioner, :

Или в Double или при преобразовании float ставилась запятая как разделитель, если системная локаль русская. Отрыто в какой-то библиотеке для foxpro

Нет такого в toString(). Там всегда точка.

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

Вообще не совсем понятно, откуда у тебя баг, т.к. судя по исходникам всё таки должно работать. Это я не к тому, что equals там стоит использовать, но всё же.

    public boolean equals(Object obj) {
        return obj instanceof Date && getTime() == ((Date) obj).getTime();
    }

С BigDecimal - это всё понятно, тут ты сам их сравниваешь, делаешь new и всё такое, знаешь откуда они появились.

Не уверен, что тебе тут всё понятно. Суть в том, что в BigDecimal размерность (число цифр после запятой) считаются частью значения при сравнении, поэтому 1.1 == 1.1, но 1.1 != 1.10. Если хочешь сравнивать, как числа, надо использовать compareTo.

Меня это слегка унгетает. Чувствую я в 2к20 они опять уволят ту макау, которая это писала, наймут новую и опять всё перепишут.

Маловероятно. Класс java.util.Date из 1994 года и сделан откровенно плохо. К java.time претензий нет.