-2

看到这个我就懵了：

  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();
    }

它确实以粗体记录Note （参见https://docs.oracle.com/javase/7/docs/api/java/sql/Timestamp.html）

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

4

3 回答 3

3
于 2018-01-06T23:18:36.680 回答
2

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

为什么可能只有作者知道，没有记录。但是 super.equals(this) 也不会尊重 equals 的契约。由于 Date 错过了纳秒精度，唯一的方法就是把纳秒排除在外。但这会导致两个不相等的 Timestamp 实例（具有不同的 nano 值）都等于同一个 Date 实例的情况，这意味着实现不具有传递性。

于 2018-01-03T10:56:59.650 回答
2

Date.equals需要Dates，所以super.equals不可行。 Timestamp.equals被 a 重载，equals(Timestamp ts)所以也遵守平等契约，需要Timestamps。

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

Timestamp 的 nanos 可能是新时间 API 的新增功能，在旧日期中不可用。

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

Timestamp#equals(Object)
    checks for both to be a Timestamp (as by contract)
    calls Timestamp#equals(Timestamp)

Timestamp#equals(Timestamp)
    calls Date#equals
    and then also compares the extra nanos fields

对于“不可行”，我的意思是没有比较两个对象的所有方面。

于 2018-01-03T11:12:27.160 回答