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

[Daniel Fuchs]

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.
>>
>>
>