Paulex Yang 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.
Hi Paulex,
To restrict the scope of the set of serializable types to be
compatibility tested we could start by looking for those that are
abstract types which get instantiated via factory methods. The abstract
class java.util.TimeZone is a perfect example while concrete type
java.util.SimpleTimeZone does successfully serialize/de-serialize across
Harmony and the RI.
Such a testing effort still sounds pretty daunting though.
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.
Interestingly enough, the RI Javadoc "specification" for the
java.util.TimeZone factory method does contain the telling phrase "the
source of the default TimeZone may vary with implementation". Sure, on
its own that may not emphasise that a user could hit
serialization/de-serialization problems if working across different
implementations - but it hopefully does serve to alert users that the
type of JRE does matter when invoking that method (and perhaps writing
mission-critical applications that rely on storing the returned object
in serialized form is not a great idea). At a very minimum, the quoted
RI Javadoc (and equivalents throughout the rest of the Javadoc files)
should be expanded to explain the potential serialization issue when a
concrete type depends on the JRE.
Best regards,
George
Thanks,
Mikhail
