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.
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.
Agree. I'm just wondering what we shall say in Harmony JavaDoc. It's RI
(SUN) who breaks its spec.
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?
Thanks,
Stepan Mishura
Intel Middleware Products Division
On 3/8/06, Paulex Yang <[EMAIL PROTECTED]> wrote:
Mikhail
Mikhail Loenko wrote:
2006/3/7, Geir Magnusson Jr <[EMAIL PROTECTED]>:
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
--
Richard Liang
China Software Development Lab, IBM
