Миграция из Java Calendar в Joda Date Time

Раньше, когда я впервые разрабатывал программное обеспечение, связанное с запасом, я решил использовать java.util.Date для представления информации о дате/времени запаса.

Позже я понимаю, что большинство методов в java.util.Date устарело. Поэтому очень скоро я реорганизую весь свой код, чтобы использовать java.util.Calendar

Однако есть два недостатка, с которыми я сталкиваюсь.

Конструкция java.util.Calendar является сравнительной медленнее, чем java.util.Date
Внутри метода getCalendar класса Stock для accessors мне нужно клонировать копию, так как Calendar является изменяемым классом

Вот текущий исходный код Stock.java

Недавно я обнаружил Joda-Time. Я делаю следующий бенчмаркинг, создавая 1 000 000 java.util.Date, java.util.Calendar и org.joda.time.DateTime. Я обнаружил, что org.joda.time.DateTime работает лучше, чем java.util.Calendar, во время создания экземпляра.

Ниже приведен сравнительный результат .

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

Как вы думаете, стоит ли мигрировать из Java Calendar в Joda Date Time, чтобы повысить производительность приложения? Есть ли какая-нибудь ловушка, на которую нужно обратить внимание?

Ответ 1

Обратите внимание, что java.util.Date тоже изменен - поэтому, если проблема теперь вы используете Calendar, это было бы проблемой при использовании Date тоже. Тем не менее, использование Joda Time определенно стоит того, что он намного лучше API.

Насколько вы уверены, что производительность на самом деле является проблемой в вашем конкретном приложении? Вы говорите, что будет создано "много экземпляров" Stock... сколько? Вы его профилировали? Я бы не ожидал, что это действительно существенно повлияет на большинство ситуаций. На графике сравнения не видно, что вы на самом деле измеряете.

Переход на Joda Time - хорошая идея в целом, но я бы измерил производительность, чтобы увидеть, какая разница для вас действительно.

Ответ 2

Зачем вам нужен Calendar в вашем классе Stock? Я думаю, что использование Date для представления точки во времени является прекрасным. Это похоже на то, что вы хотите, потому что вы хотите, чтобы объект Calendar в складе был неизменным, что должен быть класс Date, если вы игнорируете устаревшие методы.

Вы можете использовать временный Calendar, когда вам нужно выполнить временные операции над Date вне класса Stock:

Calendar calendar = Calendar.getInstance();
calendar.setTime(stock.getDate());
System.out.println(calendar.getYear());

Подобным образом вы все равно можете сохранить Date в своем классе Stock, который должен иметь лучшую производительность при сохранении и извлечении объектов Stock из хранилища данных. Если вы выполняете сразу несколько операций, вы также можете повторно использовать один и тот же объект Calendar.

Если вам не нравится интерфейс Calendar, вы все равно можете использовать Joda Time для выполнения операций времени. Вероятно, вы можете конвертировать даты в и из Joda Time, если это необходимо, выполнять операции времени и сохранять Date объекты в классе Stock.

Ответ 3

Если java.util.Calendar экземпляры, подлежащие замене на org.joda.time.DateTime, анализируются и/или отформатируются на конкретный шаблон, например

String format = "YYYY-MM-dd HH:mm:ss";

Внутри сигнатур метода для типов параметров и возвращаемых значений, а также деклараций переменных

и экземпляры, отменяют целые слова вхождения имен классов Calendar (с

DateTime) и SimpleDateFormat (с DateTimeFormatter), соответственно

Замените оператор создания экземпляра форматирования, например
```
formatter = new SimpleDateFormat(format);
```
с
```
formatter = DateTimeFormat.forPattern(format);
```

Заменить вызовы методам `SimpleDateFormat ', например

String dateStr = formatter.format(Calendar.getInstance().getTime());

String dateStr = DateTime.now().toString(formatter);

formatter.parse(dateStr);

DateTime.parse(dateStr, formatter);

Ответ 4

В прошлом я использовал Joda, и это потрясающая библиотека.

Что касается производительности, вам придется протестировать ее, к сожалению. Но рефакторинг вашего кода кажется слишком большим. Лично я использовал Date во всем моем приложении (включая хранилище БД и извлечение), и использовал Joda только тогда, когда мне нужна обработка данных. Joda вычисляет поля только тогда, когда это необходимо, поэтому я предполагаю, что накладные расходы будут намного ниже, чем использование классов Java API; кроме того, у вас не будет проблем с объектной версией для передачи и обработки объектов Date в вашей БД, сериализации объектов и т.д. Я не ожидаю, что Joda нарушит такую совместимость, но менее вероятно использовать Date.

Ответ 5

Лучше всегда переходить к юдовому времени. Но это действительно стоит переместиться в joda-time для вашего проекта, основываясь на ваших случаях использования, связанных с использованием даты. Посмотрите на слайд номер 46 в презентации для номеров, связанных с производительностью, для некоторых операций текст ссылки