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 > 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) > >> ... ... > >> > >> > > > > > >
