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 14:34:13 GMT
Mikhail Loenko wrote:
> The problem is serial form contains class name "sun.foo"
> and if you deal with "o.a.h.foo" then serialization framework
> will never know that you class's readObject() is to be invoked.
>   
Yep, you're right : it really is a lot worse than I originally envisaged :-(

> Another option is provide 'pairs' to ObjectInputStream.readObject():
> for each 'foo' method it will know what is the corresponding harmony
> class.
>   
Sounds like keeping the list of pairs up to date could become a 
never-ending task :-(

Given this plus the valuable insight from Chris Gray, I'm starting to 
see "let it be" as a serious option.

Best regards,
George

> Thanks,
> Mikhail
>
>
> 2006/3/7, George Harley <george.c.harley@googlemail.com>:
>   
>> 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