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 Fri, 10 Mar 2006 09:19:22 GMT
Paulex Yang 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.
>>   
> In fact this is also my preferred choice:). So I suggest to mark the 
> JIRA 184 (the TimeZone case) as "won't fix", and wait to see if any 
> application is broken by this.

I think that the Javadoc comments in java.util.TimeZone should be 
updated to clarify precisely what this Java implementation returns from 
the static methods under discussion. It would be a small example of the 
"value add" of Harmony.

Best regards,
George

>> 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.
>>   
> Yes, currently the Harmony DOES use SimpleTimeZone, and the serialized 
> bytes by Harmony can be deserialized by RI. So it is definitely 
> possible, at least for this case.
>>  
>>> 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?
>>   
> Yes, this's my understanding of Mikhail's idea.
>
> Pls. refer to his former mail in this thread for details if you want.
>> 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
>>
>>   
>
>



Mime
View raw message