Why not use java.util.Date in Jdbc?

Question

This is a simple question: I know and have heard from almost everyone that using java.util.Date for anything in a Jdbc call is a bad idea. You should use either java.sql.Date or java.sql.Time or java.sql.Timestamp. However, what is the reason not to? I can't find a good blog post or SO post explaining it, except that sometimes people see "weird behavior".

Thanks!

EDIT:

So, I have seen this post. Yeah, the only part of that post that sort of answers my question is

...to most JDBC drivers which will happily devour it as if it was of the correct type but when you request the data afterwards, you may notice that you're actually missing stuff.

However, that doesn't really answer why.

Answer 1

Okay, so having read all the information throughout the answers, and the others posts pointed to in comments and so forth, I've decided to summarize what I learned:

The Setup:

From what I can see, there are three layers

JDBC wrapper calls (e.g. Spring's SimpleJdbcTemplate)
|
|
Raw JDBC calls (e.g. PreparedStatement)
|
|
JDBC driver (e.g. Oracle)

The First Reason

Many JDBC class wrappers, such as Spring's famous SimpleJdbcTemplate, allowed you give it a Map<String, Object> as the argument map when executing a SQL statement. This is wonderfully simple, as it hands all the conversions from the objects to the proper java.sql.* types when it uses raw JDBC under the hood. The first problem is here: what happens if you have the following:

Map<String, Object> paramMap = new HashMap<String,Object>();
paramMap.put("p_some_data", new java.util.Date());

What does Spring convert it to? A java.sql.Date? A java.sql.Timestamp? A java.sql.Time? Or does it even cast it to a java.lang.Object? As well explained by @BalusC in this answer to a different question and by another fellow here, there are big differences between those three java.sql types. So, that's the first reason not to use java.util.Date: you can't rely on the internal convention of a framework to handle the conversion for you.

The Second Reason

Now, talking about raw JDBC calls, @The Nail explained that you need these java.sql types to make JDBC calls, and he's absolutely right, which was news to me. However, there is still the dreaded setObject call. From reading the JavaDoc for that call, it seems a little ambiguous as to what it will do if give a java.util.Date. So, the second reason not to use it is because of the ambiguity there.

The Third Reason

Finally, talking about the level of the driver. I can attest with personal experience that sometimes Spring in conjunction with the Oracle driver does work with java.util.Date. Sometimes. And then sometimes it doesn't. So, because I have no clue how any particular version of any particular driver will handle a java.util.Date, it's best to be explicit. This is the third reason.

Conclusion

In general, it looks like the reason is: "JDBC is not supposed to be used with java.util.Date. If you do, you cannot be sure what will happen." This is a good enough reason for me :)