harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mikhail Loenko" <mloe...@gmail.com>
Subject Re: How to deal with this kind of serialization compatibility issue?
Date Tue, 07 Mar 2006 11:37:35 GMT
George,

2006/3/7, George Harley <george.c.harley@googlemail.com>:
> Paulex Yang wrote:
> > This kind of serialization compatibility issue may be found again
> > later, if only RI use some non-API class as default implementation of
> > serializable abstract class. So I think we need some discussion on
> > this issue for a principle.
> >
> > I propose two choice:
> > 1. just let it be
> > 2. mimic a class as RI, in this TimeZone case, create a
> > sun.util.calendar.ZoneInfo by wrapping java.util.SimpleTimeZone, it
> > works but risky and ugly, it is risky because RI may change the
> > implementation class later(which will also break RI's serialization
> > compatibility of course)
> >
> > comments?
>
> Hi Paulex,
>
> When such RI->Harmony serialization incompatibilities come to light we
> can aim to deal with it in readObject() methods added to the affected

It is not quite clear, in which class you are going to deal with readObject() ?

Are you suggesting modification of IO framework that does serialization?

Thanks,
Mikhail

> types. This will have to be done on a case-by-case basis of course. In
> this particular case I could imagine that we could catch that
> ClassNotFoundException in the method and proceed on from there.
>
> But what about Harmony->RI serialization incompatibilities ? That is,
> what about Harmony applications serializing types to files and those
> files being later read in by applications running on a RI JRE ? In some
> cases we will probably "get away with it" as the differences in
> implementation will not break compatibility. For instance, running your
> test code so that Harmony produces the .ser file and the RI reads it in
> seemed to work fine for me. But the risk of problems will always be
> there. I am not certain that writing stubs of sun.* classes is a good
> direction to set off in to counter those risks. It would be better to
> try and work with the RI providers so that their classes can cope with
> serialized Harmony types.
>
> I wonder what lessons other class library development teams have learned
> in this area ?
>
> Best regards,
> George
>
>
> >
> > Paulex Yang (JIRA) wrote:
> >> java.util.TimeZone's default implementation may cause many classes'
> >> serialization non-compatible with RI
> >> --------------------------------------------------------------------------------------------------------
> >>
> >>
> >>          Key: HARMONY-184
> >>          URL: http://issues.apache.org/jira/browse/HARMONY-184
> >>      Project: Harmony
> >>         Type: Bug
> >>   Components: Classlib      Reporter: Paulex Yang
> >>     Priority: Critical
> >>
> >>
> >> Static factory methods, java.util.TimeZone.getInstance(String) and
> >> getDefault(), are only ways to get a TimeZone instance, but Harmony
> >> and RI uses different classes as default implementation, which cause
> >> serialization non-compatible. Further, all classes whose
> >> serialization form includes TimeZone won't compatible with RI, too,
> >> for example, java.util.Calendar(with subclass),
> >> java.text.DateFormat(with subclass), etc.
> >>
> >> But the incompatiblity is hard to be imputed to Harmony, because
> >> Harmony use API class SimpleTimeZone as default implementation, but
> >> RI use a non-API class,  whose full name is sun.util.calendar.ZoneInfo.
> >>
> >> The reproduce procedure:
> >> 1. To serialize TimeZone object to a file in RI, run codes below in RI
> >> public void writeObject(){
> >>         TimeZone zone = TimeZone.getTimeZone("GMT");
> >>         ObjectOutputStream ooutput = null;
> >>         try {
> >>             ooutput = new ObjectOutputStream(new
> >> FileOutputStream("TimeZone.ser"));
> >>             ooutput.writeObject(zone);
> >>         } finally {
> >>             try {
> >>                 if (null != ooutput) {
> >>                     ooutput.close();
> >>                 }
> >>             } catch (Exception e) {
> >>             }
> >>         }
> >> }
> >>
> >> 2. Trying to deserialize this object from file, run codes below
> >> public void readObject(){
> >>         ObjectInputStream oinput = null;
> >>         try {
> >>             oinput = new ObjectInputStream(new
> >> FileInputStream("TimeZone.ser"));
> >>             TimeZone newObj = (TimeZone)oinput.readObject();
> >>         } finally {
> >>             try {
> >>                 if (null != oinput) {
> >>                     oinput.close();
> >>                 }
> >>             } catch (Exception e) {
> >>             }
> >>         }
> >> }
> >>
> >> Run in RI, passes without any failure
> >> Run in Harmony, exception throwed as below:
> >> java.lang.ClassNotFoundException: sun.util.calendar.ZoneInfo
> >>     at java.lang.Class.forName(Class.java:154)
> >>     at
> >> java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:2226)
> >> ... ...
> >>
> >>
> >
> >
>
>

Mime
View raw message