4
Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and thei...
source link: https://mail.openjdk.java.net/pipermail/discuss/2022-May/006077.html
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses
Deprecating java.util.Date, java.util.Calendar and java.text.DateFormat and their subclasses
Victor Williams Stafusa da Silva
victorwssilva at gmail.com
Sun May 8 02:36:27 UTC 2022
The java.time package was released in Java 8, far back in 2014, more than 8 years ago. It has been a long time since then. Before that, we had the dreadful infamous java.util.Date, java.util.Calendar, java.text.DateFormat and their subclasses java.sql.Date, java.sql.Time, java.sql.Timestamp, java.util.GregorianCalendar, java.text.SimpleDateFormat and a few other lesser-known obscure cases. There are plenty of reasons to avoid using Date, Calendar, DateFormat and their subclasses, otherwise there would be few to no reasons for java.time to be conceived. Applications and libraries which used or relied on those legacy classes already had plenty of time to move on and provide java.time.* alternatives. No skilled java programmer uses the legacy classes in new applications except when integrating with legacy APIs. Using those classes nowadays should be considered at least a bad programming practice, if not something worse (source of bugs, security issues, etc). Novices, unskilled, careless and lazy programmers who should know better still happily continue to use the legacy classes, pissing off those who are more enlightened. So, my proposal is pretty simple: It is time to put a @Deprecated in all of those (not for removal, though). First, let's deprecate all of them. Second, any method in the JDK returning or receiving any of those as a parameter should be equally deprecated. If there is no replacement method using the relevant classes or interfaces in the java.time package, one should be created (which is something probably pretty straightforward). If any of those methods is abstract or is part of an interface, then we have a small problem, and it should be solved on a case-by-case analysis, preferentially by providing a default implementation. I'm sure that some cases should still exist, but I doubt that any of them would be a showstopper. The negative impact is expected to be very small. Popular products like Spring and Jakarta either already moved on and provided java.time.* alternatives to their APIs or could do that quickly and easily. Anyone who is left behind, would only get some [deserved] deprecation warnings. On the positive impact side, more than just discouraging the usage of the ugly and annoying API of Date, Calendar and DateFormat for people who should know better, those classes are a frequent source of bugs that are hard do track and to debug due to their mutability and thread unsafety. Thus, we are already way past the time to make the compiler give a warning to anyone still using them. What do you think?
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK