我想说服架构经理在我们的产品中加入Joda-Time jar.
你知道使用它的任何缺点吗？
我认为Joda-Time需要不断更新,因为它包含的文件.这是一个缺点.也许我错了.
你能否澄清一下这个问题？
Jon*_*eet 57
我对Joda Time几乎都有过积极的体验.我的一个问题是在尝试构建我自己的时区时(出于正当理由,我向你保证:)我得到了一些非常奇怪的异常,并且文档对于那个特定的用例并不是很好.
但是,在大多数情况下使用它是一种乐趣 - 不变性使得代码更易于推理,并且格式化程序的线程安全性非常有用.
是的,有些文件可以保持最新 - 但至少你可以让它们保持最新.这并不是说它们包含了Java内置东西所不必要的东西,只是使用Java的机制,你只是无法保持时区之类的信息是最新的而没有明显的hackery!
基本上,使用Joda Time的+1.Java日期/时间API是Java平台IMO中最糟糕的部分之一.
Joh*_*n O 35
在我看来,Joda-Time最重要的缺点是精度:许多数据库以微秒(甚至纳秒)的精度存储时间戳.Joda-time只有几毫秒.这对我来说是不可接受的:我使用的所有"数据模型"类都需要反映数据库中数据的完整精度.图书馆对我的数据的近似或截断不会削减它.
以下是从JSR 310邮件列表中选择毫秒精度的原因:
"Joda-Time选择使用毫秒,因为它更容易转换到日期和日历." - S. Colebourne
对谁更容易？图书馆的作者,人们会认为......在我看来,当几乎所有数据库存储时间达到微秒/纳秒精度时,设计决策都是错误的.无视数据库值令人担忧.
Mat*_*ush 11
使用Joda Time时我们遇到的最大问题是与Spring和Tapestry的集成,因为他们都希望使用内置的日期和时间.我们经常在getter/setter中为日期和时间编写包装器:要么将它存储为Joda Time,要么将一组getter/setter传递给它,另一组将动态转换,并且一些类在内部存储为Java日期/时间,Joda getter/setter必须动态切换它.
基本上,这是一个令人头疼的问题,因为这些类的名称相似,除非您可以将整个架构(包括其他正在集成的库)转换为Joda Time,否则您将编写比您可能保存的更多的包装代码.通过使用Joda库.
Parleys主持Stephen Colebourne关于JSR-310的演讲, Coledourne 先生是Joda-Time和JSR-310的作者.他首先解释了Java中标准日期/时间支持的弱点以及为什么要使用替代方案.向架构管理员展示此演示文稿可能会有所帮助.我似乎无法深刻联系
Joda-Time经常更新其时区文件的原因是因为时区数据一直在变化,通常是在短时间内(今天在slashdot:闰秒在2008-12-31添加)并且并不总是科学上的动机(例如我记得一些太平洋岛屿国家改变其时区成为第一个进入2000年的国家).