The problem is serial form contains class name "sun.foo" and if you deal with "o.a.h.foo" then serialization framework will never know that you class's readObject() is to be invoked.
Another option is provide 'pairs' to ObjectInputStream.readObject(): for each 'foo' method it will know what is the corresponding harmony class. Thanks, Mikhail 2006/3/7, George Harley <[EMAIL PROTECTED]>: > Mikhail Loenko wrote: > > George, > > > > 2006/3/7, George Harley <[EMAIL PROTECTED]>: > > > >> 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 > > > > > > Hi Mikhail, > > I mean the "private void readObject(ObjectInputStream os)" method that > every type implementing the Serializable interface can contain to > provide customised de-serialization. > > Best regards, > George > > >> 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) > >>>> ... ... > >>>> > >>>> > >>>> > >>> > >> > > > > > >
