harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: How to deal with this kind of serialization compatibility issue?
Date Fri, 10 Mar 2006 11:07:00 GMT
 Paulex,

see my comments below.

On 3/10/06, Paulex Yang <paulex.yang@gmail.com> 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 <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
> >
> >
>
>
> --
> Paulex Yang
> China Software Development Lab
> IBM
>
>
>


--
Thanks,
Stepan Mishura
Intel Middleware Products Division

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