in jdk1.3 java.util.Date has a member of Calendar which in turn has java.util.SimpleTimeZone. However in j2se 1.4 onwards this has changed to sun.util.Calendar.ZoneInfo Due to this some of our webservices code which was running smoothly has started giving issues with the 1.4 version. Any idea how to resolve this version conflict and fix the issue ? Has anyone faced similar problems?
No, there is no method or member variable in class java.util.Date that is a Calendar. Not in version 1.3, and not in newer versions. Did you mean something different?
"which in turn has java.util.SimpleTimeZone."
Class Calendar has a method named getTimeZone() that returns a java.util.TimeZone. The API documentation does not say that it is a SimpleTimeZone (which is just a particular implementation of the abstract class TimeZone).
"However in j2se 1.4 onwards this has changed to sun.util.Calendar.ZoneInfo Due to this some of our webservices code which was running smoothly has started giving issues with the 1.4 version."
As long as sun.util.Calendar.ZoneInfo is also an implementation of java.util.TimeZone, it should not matter.
Do your webservices rely on the fact that getTimeZone() returns a SimpleTimeZone? If so, then it is your own fault that it isn't compatible with newer versions. The API specification only says that getTimeZone() returns a TimeZone, and it doesn't say which exact subclass of TimeZone is returned.
"Any idea how to resolve this version conflict and fix the issue ?"
Rewrite your webservice so that it doesn't rely on the fact that getTimeZone returns a SimpleTimeZone. For example:
as far as the code design goes ... the request is build into Request object using castor data types and the <TimeStamp> tag in the request xml corresponds to a Date field in the Request object. so basically when the Request is build using the castor types, the Date object fails to parse and it is null.
Strange. Why does your program mess with the private parts of class java.util.Date? You're not supposed to access private members of classes - that's exactly the reason why they're private.
Only the public / protected API of the standard Java classes is guaranteed to remain the same in newer versions (except for methods and members that are deprecated - but until now even deprecated stuff has never been removed in newer versions of the JDK).
Can you show us some code that works on JDK 1.3, but fails on JDK 1.5?
From your description of the code design, I don't see why it would be necessary to access private members in class java.util.Date.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com