Ran into a tricky situation today. I have a Calender object in my class, which I serialized, and then deserialized back. This was in the codebase for a while, and was working fine. Although, of late, heard people complaining that they occasionally see a ClassCastException : java.util.SimpleTimeZone cannot be cast to sun...blahblahblah..ZoneInfo.
We are running on Java1.6, though the dev environment is a couple of releases lesser then the production environment:
dev env -> JRE 1.6_10
prod -> JRE 1.6_13
Has anyone faced this issue before ? Do you suspect that the error is due to the change in release versions ?
Any inputs are highly appreciated...thanks in advance...
Moving thread as too difficult a question for "beginning".
Joined: Apr 26, 2007
Thank you for your responses guys...
However, I tried as per the bug report & also, have seen somewhere that Sun/Oracle addressed this issue starting from versions 1.6_10 onwards... I am running on 1.6_13, and am still getting this. Marking my Calendar object as transient is not an option I have, and hence am stuck at a roadblock.
I will keep this thread open to see if some other input comes in. Meanwhile, if I am able to break this case, will update here.
You said you have serialized data. I can imagine that if you have old serialized objects (from when you were using an older JDK 6 version), you might still get that error even when you try to load them when using a newer JDK 6 version.
Are you storing those serialized objects for a longer time? Note that serialization is not very well suited for long-term storage. The problem is that serialized objects have a very direct mapping to the Java code, so any change in a Java class might make it impossible to read the serialized object back. It's not only a problem with your own source code; if Sun for example would change something in a Java update, it could happen that you suddenly can't read your serialized objects anymore.
Serialization is good for sending objects over a network or for temporary storage (a cache, for example), but not for long-term storage. You should use a well-defined data format for that which is not tied so tightly to the source code.
However this is an inherited codebase that I am talking about. The classes here might well be as old as I am !!!
Serialization is used quite liberally, and there is this very complex object which has a Calendar instance somewhere deep inside its object hierarchy, which is triggering this problem. I could add a "transient" to th Calendar definition, and get out of this hell, but it might break something else. When I googled this situation, I understood that I am not the first one in the world to hit this particular roadblock, so I was wondering if someone managed to overcome this situation in some other fashion.
Thanks a lot for your pointers... I would keep looking into this further (...but any help is welcome )