考虑将12GHz频段用于5G服务

还有这么重写父类方法的?还有王法吗?这也算是JDK能干出来的事?赤裸裸的违背里氏替换原则等众多设计原则，子类能力竟然比父类小，使用起来简直让人云里雾里。

java.util.Date的三个子类均位于java.sql包内，他们三是通过Javadoc描述来进行分工的：

• java.sql.Date：只表示日期
• java.sql.Time：只表示时间
• java.sql.Timestamp：表示日期 + 时间

这么一来，似乎可以“理解”java.sql.Date为何重写父类的getHours()方法改为抛出IllegalArgumentException异常了，毕竟它只能表示日期嘛。但是这种通过继承再阉割的实现手法你们接受得了?反正我是不能的~

罪状五：无法处理时区

因为日期时间的特殊性，不同的国家地区在同一时刻显示的日期时间应该是不一样的，但Date做不到，因为它底层代码是这样的：
 

尼玛，原来 2021 - 1900 = 121是这么来的。那么问题来了，为何是1900这个数字呢?

月份，竟然从0开始，这是学的谁呢?简直打破了我认为的只有index索引值才是从0开始的认知啊，这种做法非常的不符合人类思维有木有。

• ❝索引值从0开始就算了，毕竟那是给计算机看的无所谓，但是你这月份主要是给人看的呀❞

罪状三：Date是可变的

oh my god，也就是说我把一个Date日期时间对象传给你，你竟然还能给我改掉，真是太没安全感可言了。
 

烂归烂，想一想什么样的烂API对你的产生影响会是最大的呢?答：很常用却很烂的。倘若一个API设计得很烂但你很少用或者几乎不用接触，你也不会对它产生很大厌恶感。打个比方，一堆屎本身很臭，但若你并不需要走到它身旁也就闻不到，自然就不会觉得它有多碍眼了。

回到这个统计结果来，EJB 2.x的API设计得最烂这个结果无可厚非，但站在时间维度的现在(2021年)回头来看，是可以完全忽略它了，毕竟现在的我们绝无可能再接触到它，再烂又有何干呢?

EJB 2.x这个老古董，相信在看文章的绝大部分同学都没见过甚至没听过它吧，A哥2015年入行，一上来Spring 4.x嘎嘎就是干，从未接触过EJB。

• ❝说明：这个统计是2010年做的，那会EJB2.x的使用量还比较大，因此上了“榜首”❞

XML/DOM设计得也不好，但已完全被第三库(如dom4j)取代，后者成为了事实的标准;AWT/Swing是市场的抉择，你用Java开发界面才会用到，否则不会接触，属于正常。

最后再看“屈居”第二名的Date/Time/Calendar日期时间API，它就不得了了。毕竟此API有个很大的特点：哪怕到了现在(2021年)依旧非常常用。所以，它设计得烂带来的实际影响是蛮大的。

下面就来具体了解下它有哪些坑爹的设计和槽点，一起不吐不快。

日期时间API的七宗罪

 

（编辑：潍坊站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!