Comments 4
Отличное дополнение к предыдущей части!
Я начал недавно рефакторить код и избавляться от Joda Time — многие из описаных вещей, особенно runtime exceptions из-за несовместимости многих преобразований или из-за отсутствия часового пояса, усложняют процесс.
Хотя при анализе становится понятно, что поведение действительно логично и корректно, но процесс разработки это не упрощает.
Также поначалу выстаиваются довольно дикие цепочки из вызовов (особенно когда надо сохранять обратную совместимость и все преобразовывать из/в старую Date). Тянет написать какой-то best practices guide для внутреннего использования.
Я начал недавно рефакторить код и избавляться от Joda Time — многие из описаных вещей, особенно runtime exceptions из-за несовместимости многих преобразований или из-за отсутствия часового пояса, усложняют процесс.
Хотя при анализе становится понятно, что поведение действительно логично и корректно, но процесс разработки это не упрощает.
Также поначалу выстаиваются довольно дикие цепочки из вызовов (особенно когда надо сохранять обратную совместимость и все преобразовывать из/в старую Date). Тянет написать какой-то best practices guide для внутреннего использования.
Подскажите, пожалуйста, чем вы рисовали диаграммы классов.
в ходе работы генерируется большее количество объектов. Например получение текущей временной точки через Instance.now() кроме самого экземпляра java.time.Instance создает еще и java.time.Clock на каждый запрос, хотя это вообще ему ни к чему — в текущей реализации достаточно было бы вызова System.currentTimeMillis().
Это на самом деле нестрашно: такие объекты JIT-компилятор обычно легко выкашивает.
Sign up to leave a comment.
Java и время: часть вторая