重写java.util.Date已弃用方法且不修改返回逻辑是否属于不良实践？

你提到的方案确实可以让IDE在调用你自定义类的这几个方法时，不再触发java.util.Date相关的弃用警告，但该做法存在严重的设计缺陷，非常不推荐使用：

• 仅掩盖警告没有解决根本问题：getYear()、getMonth()、getDay()本身的设计问题依旧存在，比如getYear()返回值为实际年份减1900、getMonth()返回值从0开始计数，很容易引发业务逻辑bug，消除警告等于主动移除了风险提示。
• 如果你确实不想让团队使用这些方法，更合理的做法是重写时直接抛出UnsupportedOperationException，同时保留@Deprecated注解并标注替代方案：

@Override
@Deprecated(since = "1.0", forRemoval = false)
public int getYear() {
    throw new UnsupportedOperationException("getYear()已弃用，请使用toLocalDate().getYear()替代");
}

@Override
@Deprecated(since = "1.0", forRemoval = false)
public int getMonth() {
    throw new UnsupportedOperationException("getMonth()已弃用，请使用toLocalDate().getMonthValue()替代");
}

@Override
@Deprecated(since = "1.0", forRemoval = false)
public int getDay() {
    throw new UnsupportedOperationException("getDay()已弃用，请使用toLocalDate().getDayOfMonth()替代");
}

• 如果你坚持要保留父类的原实现，需要在你重写的方法上添加@SuppressWarnings("deprecation")注解，否则你自己的类代码中调用父类弃用方法时依旧会触发警告：

@Override
@SuppressWarnings("deprecation")
public int getYear() {
    return super.getYear();
}

更推荐从根源上规避该问题：JDBC 4.2及以上版本已经原生支持java.time包下的日期类型，主流ORM框架也都完成了适配，完全不需要继承java.sql.Date做数据库适配，业务层直接使用LocalDate处理日期逻辑即可，既能避免旧API的设计缺陷，也不会有弃用警告的问题。

内容的提问来源于stack exchange，提问作者Carl Eric Doromal