RFR (JAXP): 8033980 : Xerces Update: datatype XMLGregorianCalendarImpl and DurationImpl

[Alan Bateman]

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.