Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: neutral (hermes.apache.org: 64.74.244.71 is neither permitted
 nor denied by domain of geir@pobox.com)
Message-ID: <440D8CF2.4030304@pobox.com>
Date: Tue, 07 Mar 2006 08:38:58 -0500
From: Geir Magnusson Jr <geir@pobox.com>
Reply-To: geir@pobox.com
User-Agent: Thunderbird 1.5 (Windows/20051201)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: How to deal with this kind of serialization compatibility issue?
References: <176117377.1141718258821.JavaMail.jira@ajax>
	 <440D3FD9.3060000@gmail.com>
 <440D6A11.20106@googlemail.com>	 <906dd82e0603070337r45239913h@mail.gmail.com>
	 <440D743B.6010306@googlemail.com>
 <906dd82e0603070426i5c23890di@mail.gmail.com>
In-Reply-To: <906dd82e0603070426i5c23890di@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

This is somewhat terrifying, isn't it?  Are there really references to 
com.sun.* in serialized API objects?  This *has* to be a bug in the 
whole spec if so...

Is serialization called out as being non-portable?

(I never thought of this before because I always worked in homogeneous 
JRE environments...)

geir

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.
> 
> Another option is provide 'pairs' to ObjectInputStream.readObject():
> for each 'foo' method it will know what is the corresponding harmony
> class.
> 
> 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)
>>>>>> ... ...
>>>>>>
>>>>>>
>>>>>>
>>>
>>
> 
>