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:31:45 GMT
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
>>
>>   
>


Mime
View raw message