RFR (JAXP): 8033980 : Xerces Update: datatype XMLGregorianCalendarImpl and DurationImpl
Alan.Bateman at oracle.com
Wed Feb 12 19:45:42 UTC 2014
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
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
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
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.
More information about the core-libs-dev