Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » How to initialize a XMLCalendar
How to initialize a XMLCalendar [message #416068] Wed, 16 January 2008 23:19 Go to next message
Will Horn is currently offline Will HornFriend
Messages: 265
Registered: July 2009
Senior Member
The fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=203510 is in,
which solves one direction of the comparison issue, but as mentioned in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=191219, a class cast
exception can still occur if equals is called on a
XMLGregorianCalendarImpl with an XMLCalendar as the argument.

I ran into this because I had programatically initialized a
XMLGregorianCalendar field on my eobject to the current date using
DatatypeFactory.newXMLGregorianCalendarDate (which creates a
XMLGregorianCalendarImpl). Later, a new date was set which was an
XMLCalendar. During NotificationImpl.isTouch(), equals is called and
the Sun JVM throws the exception.

It seems to me that due to the Sun bug, all EMF code should be careful
to use XMLCalendar implementations, which leads me to the question of
how best to initialize one.

The only way I see is use XMLTypeFactory.createDate, but this requires a
string. Is there any other way? XMLTypeFactory.convertDate looks like
it should work off a java.util.Date, but it's deprecated. What's the
reason for deprecation?

Thanks,
Will
Re: How to initialize a XMLCalendar [message #416069 is a reply to message #416068] Thu, 17 January 2008 00:16 Go to previous messageGo to next message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Will,

It would be good to open a bug against the Sun JVM because there is no
reason for any one implementation to assume there it is the one and
only implementation of a public abstract class provided by the JDK. All
methods should respect the public class' API and should be written only
to assume that the public abstract class' method are implemented...

The Object-based methods in the XMLTypeFactory are superseded for Java
5.0 by the more strongly typed methods that use the actual XML Schema
appropriate types that weren't available in a 1.4 JDK. Even the types
of the methods generated for the XML Schema data types not supported in
1.4 will have changed from java.lang.Object to XMLGregorianCalendar,
Duration, or QName...


Will Horn wrote:
> The fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=203510 is
> in, which solves one direction of the comparison issue, but as
> mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=191219, a
> class cast exception can still occur if equals is called on a
> XMLGregorianCalendarImpl with an XMLCalendar as the argument.
>
> I ran into this because I had programatically initialized a
> XMLGregorianCalendar field on my eobject to the current date using
> DatatypeFactory.newXMLGregorianCalendarDate (which creates a
> XMLGregorianCalendarImpl). Later, a new date was set which was an
> XMLCalendar. During NotificationImpl.isTouch(), equals is called and
> the Sun JVM throws the exception.
>
> It seems to me that due to the Sun bug, all EMF code should be careful
> to use XMLCalendar implementations, which leads me to the question of
> how best to initialize one.
>
> The only way I see is use XMLTypeFactory.createDate, but this requires
> a string. Is there any other way? XMLTypeFactory.convertDate looks
> like it should work off a java.util.Date, but it's deprecated. What's
> the reason for deprecation?
>
> Thanks,
> Will


Ed Merks
Professional Support: https://www.macromodeling.com/
Re: How to initialize a XMLCalendar [message #416070 is a reply to message #416069] Thu, 17 January 2008 01:22 Go to previous messageGo to next message
Jason Henriksen is currently offline Jason HenriksenFriend
Messages: 231
Registered: July 2009
Senior Member
I have to pipe up here and say that my company has had a litany of
problems with XMLGregorianCalender implementations.

We've had all kinds of fun such as:
- Different vendors using different calendar implementations
(like the com.sun.org.apache packages! What the hey is that!?!?)
- CCE during comparisons
- CCE during hibernate persistence
- All manner of SOAP / XML mapping problems

For us it has gotten bad enough for us to abandon all of the XSD
calendar and time functionality. The sad fact is that these features
simply don't work reliably. I can blame anyone I want but knowing who
to blame doesn't help me deliver anything.

Instead we've defined a new type in XSD which has a date attribute and a
time attribute. We let both attributes be strings and use XSD to
restrict the valid values. We make the restrictions match what the DB
wants a date string to look like and we provide some utility methods to
convert the strings into date types for java code uses. It's a pity we
have to do this ourselves, but out implementation always works while the
sun/ibm/apache stuff just doesn't play nicely together.

In then end their stuff is doing to same parsing and conversions as our
code, so it doesn't really hurt anything to do this. Plus, you're
company will spend way more money on developer wasted due to XMLCalendar
problems than it will lose in lost performance due to String/Date
conversions.

Just letting you know,

Jason Henriksen



Ed Merks wrote:
> Will,
>
> It would be good to open a bug against the Sun JVM because there is no
> reason for any one implementation to assume there it is the one and
> only implementation of a public abstract class provided by the JDK. All
> methods should respect the public class' API and should be written only
> to assume that the public abstract class' method are implemented...
>
> The Object-based methods in the XMLTypeFactory are superseded for Java
> 5.0 by the more strongly typed methods that use the actual XML Schema
> appropriate types that weren't available in a 1.4 JDK. Even the types
> of the methods generated for the XML Schema data types not supported in
> 1.4 will have changed from java.lang.Object to XMLGregorianCalendar,
> Duration, or QName...
>
>
> Will Horn wrote:
>> The fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=203510 is
>> in, which solves one direction of the comparison issue, but as
>> mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=191219, a
>> class cast exception can still occur if equals is called on a
>> XMLGregorianCalendarImpl with an XMLCalendar as the argument.
>>
>> I ran into this because I had programatically initialized a
>> XMLGregorianCalendar field on my eobject to the current date using
>> DatatypeFactory.newXMLGregorianCalendarDate (which creates a
>> XMLGregorianCalendarImpl). Later, a new date was set which was an
>> XMLCalendar. During NotificationImpl.isTouch(), equals is called and
>> the Sun JVM throws the exception.
>>
>> It seems to me that due to the Sun bug, all EMF code should be careful
>> to use XMLCalendar implementations, which leads me to the question of
>> how best to initialize one.
>>
>> The only way I see is use XMLTypeFactory.createDate, but this requires
>> a string. Is there any other way? XMLTypeFactory.convertDate looks
>> like it should work off a java.util.Date, but it's deprecated. What's
>> the reason for deprecation?
>>
>> Thanks,
>> Will
Re: How to initialize a XMLCalendar [message #416075 is a reply to message #416070] Thu, 17 January 2008 09:27 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 33113
Registered: July 2009
Senior Member
Jason,

Comments below.

jason henriksen wrote:
>
> I have to pipe up here and say that my company has had a litany of
> problems with XMLGregorianCalender implementations.
:-(
>
> We've had all kinds of fun such as:
> - Different vendors using different calendar implementations
> (like the com.sun.org.apache packages! What the hey is that!?!?)
Can you imagine the fun of taking open source, changing it arbitrarily,
including package renames, and giving nothing back, not even bug fixes?
All too often such changes produce incompatible behavior. APL is so
flexible and lenient. To their defense, by renaming it, which the IBM
JVM doesn't do, they do make it easier to use Apache's libraries
directly, given there are no name collisions.
> - CCE during comparisons
> - CCE during hibernate persistence
> - All manner of SOAP / XML mapping problems
Isn't it obvious how to do this right you might ask? You have a public
abstract class and all methods should assume only that much about the
implementation. Didn't the implementation start out right before it was
butchered? And why exactly do we need different implementations of this
anyway? Doesn't that just represent a problem for java.io.Serializeable
support? Of course there's another wonderful bit of technology...
>
> For us it has gotten bad enough for us to abandon all of the XSD
> calendar and time functionality. The sad fact is that these features
> simply don't work reliably. I can blame anyone I want but knowing who
> to blame doesn't help me deliver anything.
I find it incredible that important XML functionality should be all to
often impaired by incompatibilities. The number of times I've had to
deal with problem like hasAttributeNS(null, "name") throwing null
pointer exceptions is just too ridiculous. And why should basic things
like getting the XML encoding or the XML version out of an XML header be
so obscure as to require reflection and then have it behave differently
for different implementations; will it be known yet during
startDocument, or only after the first startElement? Will it still be
correct during endDocument. Well that depends on the implementation
doesn't it...
>
> Instead we've defined a new type in XSD which has a date attribute and
> a time attribute. We let both attributes be strings and use XSD to
> restrict the valid values. We make the restrictions match what the DB
> wants a date string to look like and we provide some utility methods
> to convert the strings into date types for java code uses. It's a
> pity we have to do this ourselves, but out implementation always works
> while the sun/ibm/apache stuff just doesn't play nicely together.
It's too sad. And that with a plethora of standards, TCKs, and bodies
to govern all this...
>
> In then end their stuff is doing to same parsing and conversions as
> our code, so it doesn't really hurt anything to do this. Plus, you're
> company will spend way more money on developer wasted due to
> XMLCalendar problems than it will lose in lost performance due to
> String/Date conversions.
Personally I find it all too often frustrating and annoying. It makes
me wonder how XML worship became one of the world's most popular cult
practices. XML is so simple though? Yep, I realize how simple it is
the thousandth time I have to explain the implications of xmlns="abc",
or the ever popular xmlns="', on the rest of the document. That's
right, the elements are implicitly qualified, but no, the attributes are
not. So don't let the lack of element qualification make you think the
element isn't qualified, look up, look way up to see the error in your
thinking. Yes, your global elements declarations in your schema will be
qualified, but no your local elements will not be, unless of course you
declare form="qualified" or elementFormDefault="qualified". And no,
your type names in the schema will not correspond to element names in
your XML. Are you following me still? Where did you get lost? It's all
so simple. Maybe there's something wrong with you? :-P
>
> Just letting you know,
>
> Jason Henriksen
Now look what you've done. In sharing your frustrations you've made me
rant! I'll have to add the disclaimer that the opinions I've expressed
are my own not someone else's and that I woke up really early...
>
>
>
> Ed Merks wrote:
>> Will,
>>
>> It would be good to open a bug against the Sun JVM because there is
>> no reason for any one implementation to assume there it is the one
>> and only implementation of a public abstract class provided by the
>> JDK. All methods should respect the public class' API and should be
>> written only to assume that the public abstract class' method are
>> implemented...
>>
>> The Object-based methods in the XMLTypeFactory are superseded for
>> Java 5.0 by the more strongly typed methods that use the actual XML
>> Schema appropriate types that weren't available in a 1.4 JDK. Even
>> the types of the methods generated for the XML Schema data types not
>> supported in 1.4 will have changed from java.lang.Object to
>> XMLGregorianCalendar, Duration, or QName...
>>
>>
>> Will Horn wrote:
>>> The fix for https://bugs.eclipse.org/bugs/show_bug.cgi?id=203510 is
>>> in, which solves one direction of the comparison issue, but as
>>> mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=191219, a
>>> class cast exception can still occur if equals is called on a
>>> XMLGregorianCalendarImpl with an XMLCalendar as the argument.
>>>
>>> I ran into this because I had programatically initialized a
>>> XMLGregorianCalendar field on my eobject to the current date using
>>> DatatypeFactory.newXMLGregorianCalendarDate (which creates a
>>> XMLGregorianCalendarImpl). Later, a new date was set which was an
>>> XMLCalendar. During NotificationImpl.isTouch(), equals is called
>>> and the Sun JVM throws the exception.
>>>
>>> It seems to me that due to the Sun bug, all EMF code should be
>>> careful to use XMLCalendar implementations, which leads me to the
>>> question of how best to initialize one.
>>>
>>> The only way I see is use XMLTypeFactory.createDate, but this
>>> requires a string. Is there any other way?
>>> XMLTypeFactory.convertDate looks like it should work off a
>>> java.util.Date, but it's deprecated. What's the reason for
>>> deprecation?
>>>
>>> Thanks,
>>> Will


Ed Merks
Professional Support: https://www.macromodeling.com/
Previous Topic:problems with headless invocation of Ecore2GenModel
Next Topic:Loading EMF model instances with different xml namespace prefix
Goto Forum:
  


Current Time: Thu Mar 28 18:59:22 GMT 2024

Powered by FUDForum. Page generated in 0.03993 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top