为什么java.sql.Timestamp会扩展java.util.Date

当我看到这一点时，我感到困惑：

  public class Timestamp extends java.util.Date {
    //...
    public boolean equals(java.lang.Object ts) {
      if (ts instanceof Timestamp) {
        return this.equals((Timestamp)ts);
      } else {
        return false;
      }
    }
    public int hashCode() {
        return super.hashCode();
    }

它确实是用粗体的注释记录的 （见附件）

对我来说，做出如此糟糕决定的原因是什么？ 当与java.util.Date对象进行比较时，为什么不调用super.equals（this）以使相等比较对称

做出这样一个对我来说非常糟糕的决定的原因是什么？当与java.util.Date对象进行比较时，为什么不调用super.equals（this）以使相等比较对称

---

原因可能只有作者知道，没有记录在案。但是super.equals（这个）也不会尊重平等的契约。由于日期未达到纳秒精度，所以实现相等的唯一方法是忽略纳秒。但这将导致两个不相等的时间戳实例（具有不同的nano值）都等于同一个日期实例的情况，这意味着实现是不可传递的。

Date.equals

需要

Date

s，因此

super.equals

是不可行的。

Timestamp.equals

被

equals（Timestamp ts）

重载，因此也遵守平等契约，要求

Timestamp

s

过载有点设计过度；但我见过更糟糕的设计

---

时间戳的Nano可能是新的时间API添加的，在旧日期中不可用

考虑到新的时间API可能会在不久的将来取代这个类，我认为没有理由提出任何更改请求。（SQL时间类现在有点多余。）

---

我说的“不可行”是指没有比较两个对象的所有方面。

相反，使用java.time 正如其他人所说：

• 这个类继承是一个糟糕的设计，一个有缺陷的黑客
• 现在没有意义了，因为这个类现在是遗留的，被替代了

避免在java.time包之外找到所有旧的遗留日期时间类

对于数据库，请使用符合的驱动程序直接与数据库交换java.time对象。您可以完全忘记

java.sql.Timestamp

存储：

Instant instant = Instant.now() ;
myPreparedStatement.setObject( … , instant ) ;

检索：

Instant instant = myResultSet.getObject( … , Instant.class ) ;

---

关于java.time 该框架内置于Java8及更高版本中。这些类取代了麻烦的旧日期时间类，例如，&

该项目现已启动，建议迁移到类

要了解更多信息，请参阅。并搜索堆栈溢出以获得许多示例和解释。规格是

从哪里获得java.time类

• ，及以后
  • 内置的
  • 标准JavaAPI的一部分，带有捆绑实现
  • Java9添加了一些次要功能和修复
• 及
  • 大部分java.time功能都在中向后移植到Java6和Java7
• • 该项目专门为Android采用了ThreeTen Backport（如上所述）
  • 看

---

该项目使用其他类扩展了java.time。这个项目是java.time将来可能添加的一个试验场。您可能会在这里找到一些有用的类，例如、、和。

，因为以前做过错误的决定。这是一个非常古老的api。如果

Date.equals（）。但是，当他们在JDK1.1中添加
java.sql
包时，他们不敢在
Date
类中进行这种更改，因为这在JDK1.0中就已经存在了。好消息是，您不必在意。现在，您可以将
java.time.Instant
和
java.time.LocalDateTime
对象存储到SQL数据库的timestamp列中，并再次以相同的类型检索它们。您根本不需要使用旧的
java.sql.Timestamp
类。投票人：三思而后行，在投票时留下评论。这个问题是有道理的，并且显示出一种深思熟虑的好奇心。这个类继承确实是一个糟糕的设计，一个有缺陷的黑客，值得探究的头脑讨论。我无法理解你的答案
Date。equals（Timestamp）
非常好，可以在纳秒内比较对象。时间戳可以在非时间戳对象的情况下实现为
/*else*/返回other.equals（this）date.equals（timestamp）
可以被调用，但是
timestamp.equals（date）
不能，因为它需要将
timestamp
缩减为一个日期。这是一个关于平等的决定，更倾向于不对称：飞机和昂贵的老爷车在使用劳斯莱斯汽车实例扩展机动车辆时并不平等。“时间戳的纳米级可能是新时代API的一个补充”，这是一个错误的说法，因为这一特性（以及整个时间戳类）自Java诞生以来就已经存在了。许多数据库都有名义上的纳秒精度，所以从一开始就引入了纳秒来支持这一点。。。如果nano==0，则不正确？：-）这正是我的情况。。。作为一种解决方法，我保证将日期对象与时间戳对象进行比较。如果nano==0，为什么还要麻烦使用时间戳呢？只需使用Date并完全避免问题：）这是jpa的事情。Hibernate（在我们使用的版本中）将日期映射到postgres的时间戳。不可能从代码中看到这一点，您必须进行调试才能看到真正发生的情况。不知道您使用的是哪个版本，但可能可以告诉JPA将其映射到某个日期。通过使用不同的注释或使用属性类型转换器。在Stackoverflow上有很多关于这个主题的帖子，我希望这个决定至少在Timestamp实现时是有意义的。但如果每个人都同意这只是一个缺陷，那就顺其自然吧。你的答案是c
Instant instant = myResultSet.getObject( … , Instant.class ) ;