Java 版本迁移已弃用的日期方法
我正在从 Java 1.1 迁移。到 Java 5。
我注意到某些方法已被弃用，例如 java.util.Date 有一个已弃用的 getYear() 方法。
我的问题是，如果 getYear() 方法保留在 1.1 中，它是否仍然可以在 Java 5 中运行
I'm migrating from Java 1.1. to Java 5.
I notice that some methods have been deprecated e.g. java.util.Date has a getYear() method which is deprecated.
My question is if the getYear() method is left as it is in 1.1 will it still function in Java 5
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
是的，它会像以前一样工作。它仅适用于在未来的 Java SE 版本中删除。弃用纯粹是文档性的，只是为您提供了同时更新代码的空间。
目前，您应该使用 的方法
java.util.Calendar或改进得多的 JodaTime API。标准 Java SE 中日期/时间 API 的替代品将类似于 JodaTime，并且仍然会出现 ( JSR-310）。本来是为JDK7计划的，但遗憾的是似乎来不及。Yes, it will just work as it was. It's only eligible for removal in future Java SE versions. The deprecation is purely documental and just gives you room to update the code in the meanwhile.
Currently, you're supposed to use either the methods of
java.util.Calendaror the much more improved JodaTime API. The replacement for date/time API's in standard Java SE will be similar to JodaTime and is still due to come (JSR-310). It was planned for JDK7, but unfortunately it doesn't seem to be in time.即使它已被弃用，它仍然可以发挥作用。他们用“更好的”（Calendar.get(Calendar.MONTH).）替换了它，但出于向后兼容性的目的，原始版本保留在那里。所以在你的情况下使用它是没有问题的。
It will still function, even though it is deprecated. They replaced it by a 'better one' (Calendar.get(Calendar.MONTH).), but the original is left there for the purpose of backwards compatibility. So it's no problem to use it in your case.
它会起作用，但开始考虑替代方案可能不是一个坏主意。
getYear 已被弃用是有原因的；与日期关联的年份实际上取决于区域设置，因此已移至 Calendar 类。 Date 类的这种重构（从数据本身中提取 Locale 依赖项）也是您在其他日期/日历相关功能中看到的。因此，在适当的情况下转向日历可能是明智之举。
也就是说，我不会用棍子碰java的日期/日历东西，我更喜欢像Apache Commons Lang和其他东西来处理大多数日期/时间相关的东西。我还听说尤达在这方面很受欢迎。
It will function but it might not be a bad idea to start thinking about alternatives.
getYear has been deprecated for a reason; the year associated with a Date is actually Locale dependent, and as such has been moved to the Calendar class. This remodeling of the Date class, which extracts the Locale dependency from the data itself, is something which you also see in other Date/Calendar related functionality. As such it might be smart to move to Calendars where appropriate.
That said, I wouldn't touch the Date / Calendar stuff of java with a stick, I prefer things like Apache Commons Lang and others to deal with most date / time related stuff. I also hear that Yoda is popular in that respect.