Hi Joe,
Couldn't all the new orig_* fields in XMLGregorianCalendarImpl be
made transient?
It looks as if they shouldn't be serialized anyway. Should they?
Not making them transient would change the serialization form, and
I'm not sure where that would take us...
best regards,
-- daniel
On 2/13/14 9:18 AM, huizhe wang wrote:
Hi Alan, Lance, and Daniel,
The Xerces serialization revision meant to create a serialization form
that would help maintain future serialization compatibility. But in
reality it itself is causing significant incompatibility as Alan pointed
out below and we discussed previously. I've removed the revision from
the patch as a result.
Please see the new webrev here:
http://cr.openjdk.java.net/~joehw/jdk9/8033980/webrev/
Thanks,
Joe
On 2/12/2014 11:45 AM, Alan Bateman wrote:
On 12/02/2014 04:26, huizhe wang wrote:
Hi Lance, Daniel,
I suggest we take this incompatibility and document it in the release
notes (we'll likely have more). I reversed DurationImpl and then
realized why the Xerces engineers made the incompatibility change
when I started on XMLGregorianCalendarImpl. It was because
XMLGregorianCalendarImpl did not implement what was recommended,
using the lexical form for serialization. In the original
implementation therefore, the impl between XMLGregorianCalendarImpl
and DurationImpl was not consistent.
Keeping this Xerces revision makes the serialization consistent in
both classes and adds the benefit of having the same source as that
of Xerces.
I think we might need to hold the horses and understand this one and
compatibility impact a bit more.
As I understand, XMLGregorianCalendar is not Serializable but the
Xerces implementation (XMLGregorianCalendarImpl) is. If someone is
using the JDK and hasn't configured an alternative DatatypeFactory
then it's an instance of
com.sun.org.apache.xerces.internal.jaxp.datatype.XMLGregorianCalendarImpl
that is serialized today. Do I have this right? I assume there is no
serialization interop between this and someone using vanilla Xerces as
the other end will be dealing with org.apache classes.
With the proposed change then you've added a writeReplace so that
going forward it will write a
com.sun.org.apache.xerces.internal.jaxp.datatype.SerializedDuration
into the stream. This isn't going to work if you've got a JDK 8 or
older on the other end, right? Also I assume this doesn't help the
Xerces interop because the fully qualified class names are still
different.
XMLGregorianCalendarImpl doesn't appear to have a readObject or other
serialization methods so I assume that if you don't change the
serialVersionUID then it would at least be possible to deserialize
something that was serialized by an older JDK. As you've added a
writeReplace then it makes me wonder why the serialVersionUID of
XMLGregorianCalendarImpl has changed. Maybe that part could be
reversed and leave the long standing value?
One thing that might help is to develop a number serialization tests
to help better understand the impact of the change.
-Alan.