> However, I'm curious to know whether or not there was a specific reason for
> adding the "drop zero milliseconds" functionality, or whether it was just
> tidying up? I'm not asking for it to be changed - it seems perfectly
> reasonable to drop the trailing zeroes - I would just like to understand the
> rationale behind it.
The main reason was to improve the roundtrip equivalence. There was an
article out there comparing various data-binding tools regarding how
much roundtrip equivalence they preserve, and the authors of the article
selected the test data such that fixing this trailing 0 issue improves
the figure for us quite a lot. So that's why we did it.
> Is there a better way to fix the problem other than modifying the JAR? I'm
> assuming that since xsdlib.jar is open-source I'm legally permitted to
> change it
Yep.
> but as this was an emergency I've not had chance to check that
> out yet. So if anybody's got an opinion on that, I'd be interested to hear
> it.
I think the code in question is actually checking if the milliseconds
field is set. So if you unmarshal a Calendar object and then marshal it
back, you'll see ".000". when you create your Calendar object by "new
GregorianCalendar()", you can manually set the milliseconds field to 0
to make the marshaller produce ".000".
Hope that helps.
regards,
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jaxb.dev.java.net
For additional commands, e-mail: users-help_at_jaxb.dev.java.net