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 Wed, 08 Mar 2006 08:12:37 GMT

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

View raw message