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
+4
A:
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.
Fortega
2010-02-22 15:12:24
+4
A:
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.Calendar or 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.
BalusC
2010-02-22 15:13:47
It seems like JSR-310 could still make JDK7: http://www.jroller.com/scolebourne/entry/new_job_impact_on_jsr
ColinD
2010-02-22 15:40:40
That's a pretty recent blog post I wasn't aware of. Thanks for sharing!
BalusC
2010-02-22 15:50:59
+2
A:
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.
extraneon
2010-02-22 15:18:51