aspose file tools*
The moose likes Java in General and the fly likes java.util.Date version conflict Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "java.util.Date version conflict" Watch "java.util.Date version conflict" New topic
Author

java.util.Date version conflict

Amey Samant
Greenhorn

Joined: Nov 18, 2005
Posts: 11
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?
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14111
    
  16

"in jdk1.3 java.util.Date has a member of Calendar"

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:


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Amey Samant
Greenhorn

Joined: Nov 18, 2005
Posts: 11
hi,
if you do javap -private java.util.Date you can see (this was done on java5)

private static final sun.util.calendar.BaseCalendar gcal;
private static sun.util.calendar.BaseCalendar jcal;
private transient sun.util.calendar.BaseCalendar$Date cdate;

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.
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14111
    
  16

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.
 
jQuery in Action, 2nd edition
 
subject: java.util.Date version conflict