JDK-4645263 : TimeZone factory methods return instance not deserializable in previous releases
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:i18n
  • Affected Version: 1.4.0
  • Priority: P4
  • Status: Closed
  • Resolution: Won't Fix
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2002-03-01
  • Updated: 2003-10-03
  • Resolved: 2003-10-03
Related Reports
Relates :  
JDK-4230123 - TimeZones loaded unnecessarily
Description

Name: nt126004			Date: 02/28/2002


FULL PRODUCT VERSION :
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

FULL OPERATING SYSTEM VERSION :
Microsoft Windows 2000 [Version 5.00.2195]

A DESCRIPTION OF THE PROBLEM :
Serialize a TimeZone to file from JDK1.4. Deserializing
from JDK1.3 throws a ClassNotFoundException.

This is related to bug 4490827 which has been closed - the
test source code below comes from there modified slightly.

REGRESSION.  Last worked in version 1.3.1

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Run the test program in JDK1.4.
2. Comment out writeObject(); in main, and compile and run
in JDK1.3.1_02.


EXPECTED VERSUS ACTUAL BEHAVIOR :
Results from step 1:

 tz=sun.util.calendar.ZoneInfo
[id="GMT",offset=0,dstSavings=0,useDaylight=false,transition
s=0,lastRule=null]


Results from step 2:

See the exception stack trace in Error Messages.


ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
	at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
	at java.security.AccessController.doPrivileged(Native Method)
	at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:299)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:286)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:255)
	at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:315)
	at java.lang.Class.forName0(Native Method)
	at java.lang.Class.forName(Class.java:195)
	at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:654)
	at java.io.ObjectInputStream.inputClassDescriptor
(ObjectInputStream.java:918)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
	at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
	at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
	at com.bglobal.gimg.glm.test.TimeZoneTest.readObject
(TimeZoneTest.java:34)
	at com.bglobal.gimg.glm.test.TimeZoneTest.main(TimeZoneTest.java:15)

This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.util.TimeZone;

public class TimeZoneTest {

    static String fName = "tmp";

    public static void main(String[] arg) throws Exception {
        writeObject();
        readObject();
    }

    static void writeObject() throws Exception {

        FileOutputStream fos = new FileOutputStream(fName);
        ObjectOutputStream out = new ObjectOutputStream(fos);

        TimeZone tz = TimeZone.getTimeZone("GMT");
        out.writeObject(tz);

        out.flush();
        out.close();
    }

    static void readObject() throws Exception {
        FileInputStream fis = new FileInputStream(fName);
        ObjectInputStream in = new ObjectInputStream(fis);

        TimeZone tz = (TimeZone) in.readObject();
        System.out.println(" tz=" + tz);

        in.close();
    }
}

---------- END SOURCE ----------
(Review ID: 139756) 
======================================================================
Comments
EVALUATION This is a known and approved incompatibility change in 1.4.0. See 4230123. ###@###.### 2002-07-15 This fix requires an API change (serialized form change) which isn't allowed in maintenance or update releases. ###@###.### 2002-10-03 Serialized objects of the default TimeZone implementation class in Tiger are compatible with 1.4.x. The compatibility problem with 1.3.x will not be fixed.
03-10-2002
WORK AROUND There are two work arounds. - Use GregorianCalendar as a wrapper When serializing a GregorianCalendar object on 1.4, it creates an SimpleTimeZone equivalent object and serializes both the ZoneInfo and SimpleTimeZone. At deserialization time, it determines which object to use. On 1.4.x, it uses ZoneInfo, on 1.3.x and earlier, it uses SimpleTimeZone. So, create a GregorianCalendar object with a TimeZone object returned by a factory method. After deserializing it, call Calendar.getTimeZone() which will return ZoneInfo on 1.4 or SimpleTimeZone on 1.3.x. A limitation is that a SimpleTimeZone equivalent can represent only a single set of daylight saving time transition rules (which restriction is one of reasons that 1.4 provides ZoneInfo, the new TimeZone subclass). A SimpleTimeZone object produced from a ZoneInfo represents the latest rules. A few time zones change daylight saving time transition rules every year or sometimes it's known that transition rules will change next year. So, a SimpleTimeZone may not represent daylight saving transition rules for a given year correctly. - Use time zone ID (String) Send only a time zone ID and call TimeZone.getTimeZone() on deserialization to create the same TimeZone object. In most cases, this will work. However, there are some limitations that 1.3.x supports a subset (~300 zones) of the 1.4 time zones (~500 zones), and 1.3.x time zone data is older than 1.4.x. 1.3.1 supports Olson tzdata2001a. 1.4 supports tzdata2001d. 1.4.1 will support tzdata2002c. ###@###.### 2002-09-10
10-09-2002