Date & Timestamp: how to get Hib. to give a java.util.Da

nodje · **Posted:** Mon May 08, 2006 6:30 am

Hibernate version:3.2.0 RC2

sample Mapping documents:

Code:

<property name="attestationPresenceDateCreation" type="java.util.Date" column="ATTESTATION_PRESENCE_DATE_CREATION" not-null="true"/>
        <property name="attestationPresenceDateMaj" type="java.util.Date" column="ATTESTATION_PRESENCE_DATE_MAJ" not-null="true"/>

Name and version of the database you are using:SQLServer 2000 SP4

Hi,

The problem I'm having is that even though all my mappings for date fields use type="java.util.Date", since I upgraded to Hibernate v3.x I got hydated entities field of java.sql.Timestamp type instead of java.util.Date.
This is causing ClassCastException when using compareTo() methods on dates, expecially at object creation when the Date fields still have an java.util.Date instance.

I tried to trace back the pb, thinking it might originate from Ehcache, but I was stopped when I realised that this is in fact TimestampType.get(ResultSet, String) implementation that is used instead of DateType.get(ResultSet, String) to hydrate the field. This is beyond my knowledge, I got no idea why the Timestamp implementation is used. Since the mapping is of type Date it seems to me that the NullableType impl. should be DateType.

Anyone ever faced this problem? Any help would be greatly appreciated!

timrobertson100 · **Posted:** Mon May 08, 2006 7:13 am

Hi,

I use dates like so:

<property name="date" not-null="false" access="property" column="date"/>

and they return java.util.Date automatically.

What happens if you take off the type="java.util.Date"?

falgunipm · **Joined:** Fri Apr 28, 2006 7:48 am **Posts:** 20

Hi,
In your mapping files, you can change the property type java.util.Date to java.sql.Timestamp as java.sql.Timestamp is a wrapper around java.util.Date you should not have a problem.

Hope this helps!!!

Regards,
falgunipm

nodje · **Posted:** Tue May 09, 2006 3:49 am

hi, thanks for your answers.

Tim, I've tried the mapping with type="date" and type="imm_date", but I always get a java.sql.Timestamp. I've checked a lot of other mappings, all my dates are mapped with java.util.Date and all result in having a java.sql.Timestamp.
Not specifying the type makes Hibernate have a guess on the type you want to use based on the porperty name. access="property" is a default option. I don't think this has to do with the mapping.

falgunipm, I already have java.sql.Timestamp type for my date fields without specifying it in the mapping!
So the change I would need to do if I would like my application to be able to work with Timestamp, would be basically to replace all Date objects by Timestamp. This is necessary, at least for Date.compareTo(Date) which leads to a ClassCastEx when one of the Date is actually a Timestamp.
This would of course be a huge work, and I would like to avoid it and just recover the original behaviour!

Thanks,

falgunipm · **Joined:** Fri Apr 28, 2006 7:48 am **Posts:** 20

Hi,
Well according to me you will have to add the type attribute in the mapping files.
You can use java.util.Date (and not java.sql.Date or java.sql.Timestamp) It should take care of most of your problems.
Regards,
falgunipm

steve · **Posted:** Tue May 09, 2006 11:17 am

This is not new behavior, not not sure how/why you do not see this problem in any previous version of Hibernate.

type="java.util.Date" maps to the org.hibernate.type.TimestampType, which returns java.sql.Timestamp instances. java.sql.Timestamp extends java.util.Date!

The following code all works perfectly fine without CCE issues:

Code:

java.util.Date date = new java.util.Date();
java.sql.Timestamp ts = new java.sql.Timestamp( date.getTime() );
System.out.println( date.compareTo( ts ) );
System.out.println( ts.compareTo( date ) );

java.util.ArrayList list = new java.util.ArrayList();
list.add( date );
list.add( ts );
java.util.Collections.sort( list );
System.out.println( "list : " + list );

java.util.HashSet set = new java.util.HashSet();
set.add( date );
set.add( ts );
System.out.println( "set : " + set );

If you absolutely, positively only want to deal with java.util.Date instances (and none of its subclasses), then consider writing a custom UserType or using one of the Calendar variants.

nodje · **Posted:** Wed May 10, 2006 3:46 am

I agree with you Steve, it should theorically work. But still I get this ClassCastEx from the Timestamp.compareTo(Date)

Here's the JDK impl. of Timestamp.compareTo().

Code:

/**
     * Compares this <code>Timestamp</code> object to the given 
     * <code>Date</code>, which must be a <code>Timestamp</code>
     * object. If the argument is not a <code>Timestamp</code> object,
     * this method throws a <code>ClassCastException</code> object.
     * (<code>Timestamp</code> objects are 
     * comparable only to other <code>Timestamp</code> objects.)
     *
     * @param o the <code>Date</code> to be compared, which must be a
     *        <code>Timestamp</code> object
     * @return  the value <code>0</code> if this <code>Timestamp</code> object
     *          and the given object are equal; a value less than <code>0</code> 
     *          if this  <code>Timestamp</code> object is before the given argument;
     *          and a value greater than <code>0</code> if this 
     *          <code>Timestamp</code> object is after the given argument.
     *
     * @exception ClassCastException if the argument is not a
     *        <code>Timestamp</code> object
     * @since   1.5
     */
    // This forwarding method ensures that the compareTo(Date) method defined
    // in java.util.Date is not invoked on a Timestamp
    public int compareTo(java.util.Date o) {
        return compareTo((Timestamp)o);
    }

I'm not sure why the've chosen this way but I'm not going to discuss it. I kind of understand that a Timestamp has to be compared with a Timestamp and not a superclass of it.

I'm almost certain that I did have instance of java.util.Date for my properties mapped with this type in the past. Moreover those ClassCastEx appeared after our migration to Hibernatev3.x.
And this actually makes some sense to me, otherwise the type choice between Timestamp and Date wouldn't be left to the user.
If type="java.util.Date" maps to the org.hibernate.type.TimestampType, then what maps to org.hibernate.type.DateType??

dinksetter · **Joined:** Tue Mar 15, 2005 4:16 pm **Posts:** 2

Has there been more activity on this topic? We're having this exact same problem. It seems as if this is a bug in the Java 5 sdk:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5103041

The code posted above by steve works in JDK 1.4.2, but breaks in JDK 1.5.0_06.

bertrand · **Posted:** Wed May 17, 2006 12:08 pm

Have a look at the following thread, it may help: http://forum.hibernate.org/viewtopic.php?t=925275

nodje · **Posted:** Thu May 18, 2006 5:00 am

Thanks Bertrand & Dinksetter for the links. Don't understand why I haven't been able to find the post when searching the forum. Well...

After all those interesting readings, I'll go for Bertrand's DateTimeType.
Coz even if JDK's bug is fixed in update7 (dunno what those guys are doing btw...), it's still too weird for me to have Timestamp in my code when my mapping requires a java.util.Date.

100% agree with Gavin on

Quote:

Note that no self-respecting code should EVER call equals on a Timestamp. Its almost as bad as for Float.

Thus I can't understand why Hibernate returns me an ugly java.sql.Timestamp. What is org.hibernate.type.DateType used for?

bertrand · **Posted:** Thu May 18, 2006 5:05 am

Life isn't perfect :(

(any credit reward if post were helpful?)

kkus · **Joined:** Wed Mar 15, 2006 1:48 pm **Posts:** 91

It happened to me when I use Oracle as db. Finally I figured out there is an old Oracle JDBC driver class in lib which prevented from using the latested one in the same lib. Hope it helps.