harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: How to deal with this kind of serialization compatibility issue?
Date Mon, 13 Mar 2006 03:46:49 GMT
As we discussed, I just attached a patch for JIRA 184 on TimeZone case
http://issues.apache.org/jira/browse/HARMONY-184

and suggested to mark this issue as "won't fix".

George Harley wrote:
> Richard Liang wrote:
>> Stepan Mishura wrote:
>>> Hi Paulex,
>>>
>>>  
>>>> Currently, we have three options:
>>>> 1. let it be, and speak it loudly in Harmony JavaDoc
>>>>
>>>>     
>>>
>>> I'd choose this option. It is open and honest - if we get unknown 
>>> class for
>>> deserialization (say sun.util.calendar.ZoneInfo or
>>> com.someCompanyName.util.MyTimeZone) we should not do any tricks and 
>>> create
>>> illusion for a user that we know how to deserialize it. Also I don't 
>>> think
>>> that "to be compatible" means to provide compatible implementation of
>>> com.sun.* classes.
>>>
>>> IMHO, the best we can do in Harmony implementation is not to do the 
>>> same
>>> "serialization bug". I mean the following: factory methods of 
>>> TimeZone class
>>> should return instances of SimpleTimeZone class. So Harmony 
>>> implementation
>>> will produce serial form that will be deserializable on any other
>>> implementation. However I don't know whether it is possible or not to
>>> implement in this way.
>>>
>>>   
>> Agree. I'm just wondering what we shall say in Harmony JavaDoc. It's 
>> RI (SUN) who breaks its spec.
>
> Hi Richard,
>
> I sent a mail on this topic yesterday (maybe my mail client is playing 
> up again ?) : the RI Javadoc for the java.util.TimeZone method 
> getDefault() states that "The source of the default TimeZone may vary 
> with implementation". Given that I personally do not think that they 
> are breaking "the spec" in this instance : they are pretty much 
> stating that this method is dependent on the Java implementation.
>
> IMHO, their Javadoc needs to make it clearer that the return from 
> their implementation of this method cannot be guaranteed to be 
> interoperate with other Java implementations. Likewise, the Harmony 
> Javadoc for the corresponding methods, and others like it that we have 
> yet to discover, should seek to remove all such ambiguities. This is a 
> great example of how our documentation can exceed that of the RI.
>
> Best regards,
> George
>
>
>>>> 2. try to compatible with RI, by creating some adapter with RI's
>>>> serializable class name, i.e. com.sun.*, etc, and the behavior is even
>>>> not necessarily compatible with RI.  we can even separate them all 
>>>> to a
>>>> new component named as "compatibility", so that it is easily modify 
>>>> them
>>>> when RI changes its mind and improve. Not sure if it is legally fine.
>>>>     
>>>
>>> IMHO, it is not the option. The word 'adapter' is used here only to 
>>> soften
>>> the fact that we have to implement a set of com.sun.* classes. And
>>> definitely they won't be "compatible". So without them we are not
>>> "compatible" and with them were are not still "compatible" :-) Why 
>>> we should
>>> do this?
>>>
>>>  
>>>> 3. also try to compatible with RI, by maintaining pairs in
>>>> ObjectInputStream, this approach maybe has less legal risk? (I have no
>>>> idea in fact.)
>>>>
>>>>     
>>>
>>> Not quite clear what you mean. Do you suggest changing serialization
>>> framework? I mean that if it detects during deserialization, for 
>>> example,
>>> sun.util.calendar.ZoneInfo it will substitute it with
>>> o.a.h.util.calendar.ZoneInfo. Right?
>>>
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>
>>>
>>> On 3/8/06, Paulex Yang <paulex.yang@gmail.com> wrote:
>>>  
>>>> Mikhail
>>>>
>>>> Mikhail Loenko wrote:
>>>>   
>>>>> 2006/3/7, Geir Magnusson Jr <geir@pobox.com>:
>>>>>
>>>>>     
>>>>>> This is somewhat terrifying, isn't it?  Are there really 
>>>>>> references to
>>>>>> com.sun.* in serialized API objects?
>>>>>>
>>>>>>         
>>>>> Yes, there are.
>>>>> For example, TimeZone.ser produced by the example from the JIRA issue
>>>>> that started this thread, refers to "sun.util.calendar.ZoneInfo"
>>>>>
>>>>>       
>>>> yes, and as I mentioned before, the TimeZone is composited by other
>>>> serializable class, so that all these classes cannot be serialization
>>>> compatible, feel like something as cancer :(
>>>>   
>>>>> Can we list all the popular applications that exchange by serialized
>>>>>       
>>>> objects
>>>>   
>>>>> and identify which objects do they send/receive?
>>>>>
>>>>>       
>>>> Rather than investigating almost infinite and uncertain(i.e. how to
>>>> define popular?) applications, I'd like to test all the serializable
>>>> class in JSE, at least it is a certain and limited set, we can just 
>>>> find
>>>> all these kind of incompatibilities one by one, and take some actions.
>>>>
>>>> Currently, we have three options:
>>>> 1. let it be, and speak it loudly in Harmony JavaDoc
>>>> 2. try to compatible with RI, by creating some adapter with RI's
>>>> serializable class name, i.e. com.sun.*, etc, and the behavior is even
>>>> not necessarily compatible with RI.  we can even separate them all 
>>>> to a
>>>> new component named as "compatibility", so that it is easily modify 
>>>> them
>>>> when RI changes its mind and improve. Not sure if it is legally fine.
>>>> 3. also try to compatible with RI, by maintaining pairs in
>>>> ObjectInputStream, this approach maybe has less legal risk? (I have no
>>>> idea in fact.)
>>>>
>>>> Any other good ideas?
>>>>
>>>> And before all of this, I cannot agree with Geir more - we should make
>>>> Sun be aware of this issue.
>>>>   
>>>>> Thanks,
>>>>> Mikhail
>>>>>
>>>>>
>>>>>       
>>>> -- 
>>>> Paulex Yang
>>>> China Software Development Lab
>>>> IBM
>>>>
>>>>
>>>>
>>>>     
>>>
>>>
>>> -- 
>>> Thanks,
>>> Stepan Mishura
>>> Intel Middleware Products Division
>>>
>>>   
>>
>
>


-- 
Paulex Yang
China Software Development Lab
IBM



Mime
View raw message