sql.Date和util.Date混用引发的bug

对于数据库的日期字段，一般会使用Date类型，比如下面的这个建表语句：

CREATE TABLE `record` (
  `id`             BIGINT UNSIGNED     NOT NULL PRIMARY KEY PRIMARY KEY AUTO_INCREMENT
  COMMENT '自增id',
  `operator_id`    BIGINT UNSIGNED                                      DEFAULT 0
  COMMENT '操作者id',
  `operator_name`  VARCHAR(128)        NOT NULL
  COMMENT '操作者名字',
  `date`           DATE                NOT NULL
  COMMENT '日期', #2017-03-23 方便按天查询
)
  ENGINE = InnoDB;

在编写和这个date对应的model的时候，一般会使用sql.Date。比如下面这样：

@Data
public class Record {
    private long id;
    private long operatorId;
    private String operatorName;
    java.sql.Date date; //使用sql.Date 类型
}

这样，在数据的写入和查询时，都不会有任何问题。但是最近，我们把sql.Date切换成了util.Date，如下面这样：

@Data
public class Record {
    private long id;
    private long operatorId;
    private String operatorName;
    java.util.Date date; //使用util.Date 类型代替sql.Date
}

切换成util.Date后，在插入数据和查询时也没有问题，但是在比较date字段的时候，发现了一个诡异的问题。如下面代码：

        Date today = new Date();
        Record record = dao.getByDate(...);
        
        if (record.getDate().equals(today)) { //false
            ...
        }

为了定位这个问题，我们首先怀疑是RowMapper映射的时候绑定出了问题，将sql.Date的值绑给了util.Date，引发不相等。
我们先来看sql.Date的源码。看它和util.Date有什么区别，如下：

public class Date extends java.util.Date {
....
}

sql.Date继承自util.Date，而且没有override equal的实现，我们可以看一下util.Date的equals方法的实现：

    public boolean equals(Object obj) {
        return obj instanceof Date && getTime() == ((Date) obj).getTime();
    }

可以看到，如果是sql.Date和util.Date做equal比较，那么应该是相等的。所以问题应该不是sql.Date和util.Date类型不同造成的。
我们继续怀疑RowMapper绑定的时候做了特殊处理，那么继续看RowMapper的实现，我们在JdbcUtils里发现下面的代码( org.springframework.jdbc.support.JdbcUtils)：

        else if (java.sql.Date.class == requiredType) {
            return rs.getDate(index);
        }
        else if (java.sql.Time.class == requiredType) {
            return rs.getTime(index);
        }
        else if (java.sql.Timestamp.class == requiredType || java.util.Date.class == requiredType) {
            return rs.getTimestamp(index);
        }

可以看到，在把sql.Date绑定到util.Date时，触发了这段逻辑：

        else if (java.sql.Timestamp.class == requiredType || java.util.Date.class == requiredType) {
            return rs.getTimestamp(index);
        }

换句话说，我们model里的util.Date被绑定上了一个sql.Timestamp类型，我们来看sql.Timestamp的实现：

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

这里可以看出，如果是timestamp类型和util.Date类型做比较，则一定会返回false。
至此，问题定位。

对于这个问题的反思，我觉得主要有几点：
1 java的date类型的整体设计，确实非常不好，里面的各种逻辑非常混乱，比如Date可以保存时分秒，还有时区引起的其他坑等等，因此应该尽量的避免使用util.Date类型
2 对于model层使用时间，如果确实有Date类型的需求，请使用sql.Date，不要使用util.Date。sql.Date在使用过程中的表现基本是一致的，而且屏蔽了时分秒的问题
3 如果数据库在设计中有夸时区的可能，应尽量避免使用Date类型，而是保持一个long的时间戳，在业务层屏蔽混乱的Date类型