Mikhail Loenko wrote:
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.
Yep, you're right : it really is a lot worse than I originally envisaged :-(
Another option is provide 'pairs' to ObjectInputStream.readObject():
for each 'foo' method it will know what is the corresponding harmony
class.
Sounds like keeping the list of pairs up to date could become a
never-ending task :-(
Given this plus the valuable insight from Chris Gray, I'm starting to
see "let it be" as a serious option.
Best regards,
George
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)
... ...
