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 Fri, 10 Mar 2006 08:11:32 GMT
George Harley wrote:
> Paulex Yang 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.
> Hi Paulex,
> To restrict the scope of the set of serializable types to be 
> compatibility tested we could start by looking for those that are 
> abstract types which get instantiated via factory methods. The 
> abstract class java.util.TimeZone is a perfect example while concrete 
> type java.util.SimpleTimeZone does successfully serialize/de-serialize 
> across Harmony and the RI.
This is good idea.
> Such a testing effort still sounds pretty daunting though.
Anyway, I think the serialization compatibility test is necessary, 
because it is an important feature, especially for many J2EE 
applications, and we should try our best to maintain the this kind of 
compatibility. It IS tedious, but just like all the tests for 
NullPointerException/IllegalArgumentException, etc. they are part of 
>> 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.
> Interestingly enough, the RI Javadoc "specification" for the 
> java.util.TimeZone factory method does contain the telling phrase "the 
> source of the default TimeZone may vary with implementation". Sure, on 
> its own that may not emphasise that a user could hit 
> serialization/de-serialization problems if working across different 
> implementations - but it hopefully does serve to alert users that the 
> type of JRE does matter when invoking that method (and perhaps writing 
> mission-critical applications that rely on storing the returned object 
> in serialized form is not a great idea). At a very minimum, the quoted 
> RI Javadoc (and equivalents throughout the rest of the Javadoc files) 
> should be expanded to explain the potential serialization issue when a 
> concrete type depends on the JRE.
> Best regards,
> George
>>> Thanks,
>>> Mikhail

Paulex Yang
China Software Development Lab

View raw message