harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Liang <richard.lian...@gmail.com>
Subject Re: How to deal with this kind of serialization compatibility issue?
Date Fri, 10 Mar 2006 08:23:00 GMT
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.
>> 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
>
>   

-- 
Richard Liang
China Software Development Lab, IBM


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message