harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From George Harley <george.c.har...@googlemail.com>
Subject Re: How to deal with this kind of serialization compatibility issue?
Date Tue, 07 Mar 2006 11:10:09 GMT
Paulex Yang wrote:
> This kind of serialization compatibility issue may be found again 
> later, if only RI use some non-API class as default implementation of 
> serializable abstract class. So I think we need some discussion on 
> this issue for a principle.
>
> I propose two choice:
> 1. just let it be
> 2. mimic a class as RI, in this TimeZone case, create a 
> sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it 
> works but risky and ugly, it is risky because RI may change the 
> implementation class later(which will also break RI's serialization 
> compatibility of course)
>
> comments?

Hi Paulex,

When such RI->Harmony serialization incompatibilities come to light we 
can aim to deal with it in readObject() methods added to the affected 
types. This will have to be done on a case-by-case basis of course. In 
this particular case I could imagine that we could catch that 
ClassNotFoundException in the method and proceed on from there.

But what about Harmony->RI serialization incompatibilities ? That is, 
what about Harmony applications serializing types to files and those 
files being later read in by applications running on a RI JRE ? In some 
cases we will probably "get away with it" as the differences in 
implementation will not break compatibility. For instance, running your 
test code so that Harmony produces the .ser file and the RI reads it in 
seemed to work fine for me. But the risk of problems will always be 
there. I am not certain that writing stubs of sun.* classes is a good 
direction to set off in to counter those risks. It would be better to 
try and work with the RI providers so that their classes can cope with 
serialized Harmony types.

I wonder what lessons other class library development teams have learned 
in this area ?

Best regards,
George


>
> Paulex Yang (JIRA) wrote:
>> java.util.TimeZone's default implementation may cause many classes' 
>> serialization non-compatible with RI
>> --------------------------------------------------------------------------------------------------------

>>
>>
>>          Key: HARMONY-184
>>          URL: http://issues.apache.org/jira/browse/HARMONY-184
>>      Project: Harmony
>>         Type: Bug
>>   Components: Classlib      Reporter: Paulex Yang
>>     Priority: Critical
>>
>>
>> Static factory methods, java.util.TimeZone.getInstance(String) and 
>> getDefault(), are only ways to get a TimeZone instance, but Harmony 
>> and RI uses different classes as default implementation, which cause 
>> serialization non-compatible. Further, all classes whose 
>> serialization form includes TimeZone won't compatible with RI, too, 
>> for example, java.util.Calendar(with subclass), 
>> java.text.DateFormat(with subclass), etc.
>>
>> But the incompatiblity is hard to be imputed to Harmony, because 
>> Harmony use API class SimpleTimeZone as default implementation, but 
>> RI use a non-API class,  whose full name is sun.util.calendar.ZoneInfo.
>>
>> The reproduce procedure:
>> 1. To serialize TimeZone object to a file in RI, run codes below in RI
>> public void writeObject(){
>>         TimeZone zone = TimeZone.getTimeZone("GMT");
>>         ObjectOutputStream ooutput = null;
>>         try {
>>             ooutput = new ObjectOutputStream(new 
>> FileOutputStream("TimeZone.ser"));
>>             ooutput.writeObject(zone);
>>         } finally {
>>             try {
>>                 if (null != ooutput) {
>>                     ooutput.close();
>>                 }
>>             } catch (Exception e) {
>>             }
>>         }
>> }
>>
>> 2. Trying to deserialize this object from file, run codes below
>> public void readObject(){
>>         ObjectInputStream oinput = null;
>>         try {
>>             oinput = new ObjectInputStream(new 
>> FileInputStream("TimeZone.ser"));
>>             TimeZone newObj = (TimeZone)oinput.readObject();
>>         } finally {
>>             try {
>>                 if (null != oinput) {
>>                     oinput.close();
>>                 }
>>             } catch (Exception e) {
>>             }
>>         }
>> }
>>
>> Run in RI, passes without any failure
>> Run in Harmony, exception throwed as below:
>> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
>>     at java.lang.Class.forName(Class.java:154)
>>     at 
>> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
>> ... ...
>>
>>   
>
>


Mime
View raw message