Paulex, see my comments below.
On 3/10/06, Paulex Yang <[EMAIL PROTECTED]> 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. Agree. > 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. Great! > > >> 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. If so it is not the option for me too. I can not find a quotation in serial spec. that explicitly forbids changing a class name during deserialization but I believe that the spec. implies this. Thanks, Stepan. 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 <[EMAIL PROTECTED]> wrote: > > > >> Mikhail > >> > >> Mikhail Loenko wrote: > >> > >>> 2006/3/7, Geir Magnusson Jr <[EMAIL PROTECTED]>: > >>> > >>> > >>>> 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 > > > > > > > -- > Paulex Yang > China Software Development Lab > IBM > > > -- Thanks, Stepan Mishura Intel Middleware Products Division
