Paulex Yang wrote:
Stepan Mishura wrote:In fact this is also my preferred choice:). So I suggest to mark the JIRA 184 (the TimeZone case) as "won't fix", and wait to see if any application is broken by this.Hi Paulex,Currently, we have three options: 1. let it be, and speak it loudly in Harmony JavaDocI'd choose this option. It is open and honest - if we get unknown class fordeserialization (say sun.util.calendar.ZoneInfo orcom.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 thinkthat "to be compatible" means to provide compatible implementation of com.sun.* classes.
I think that the Javadoc comments in java.util.TimeZone should be updated to clarify precisely what this Java implementation returns from the static methods under discussion. It would be a small example of the "value add" of Harmony.
Best regards, George
Yes, currently the Harmony DOES use SimpleTimeZone, and the serialized bytes by Harmony can be deserialized by RI. So it is definitely possible, at least for this case.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 implementationwill 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.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 anew component named as "compatibility", so that it is easily modify themwhen 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 softenthe 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 shoulddo 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 serializationframework? 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?Yes, this's my understanding of Mikhail's idea. Pls. refer to his former mail in this thread for details if you want.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 tocom.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 serializedobjectsand 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 serializableclass in JSE, at least it is a certain and limited set, we can just findall 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 anew component named as "compatibility", so that it is easily modify themwhen 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