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:53:31 GMT
Mikhail Loenko wrote:
> George,
>
> 2006/3/7, George Harley <george.c.harley@googlemail.com>:
>   
>> 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
>>     
>
> It is not quite clear, in which class you are going to deal with readObject() ?
>
> Are you suggesting modification of IO framework that does serialization?
>
> Thanks,
> Mikhail
>
>   

Hi Mikhail,

I mean the "private void readObject(ObjectInputStream os)" method that 
every type implementing the Serializable interface can contain to 
provide customised de-serialization.

Best regards,
George

>> 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