[
https://issues.apache.org/jira/browse/METAMODEL-169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14694825#comment-14694825
]
Kasper Sørensen commented on METAMODEL-169:
-------------------------------------------
Thanks for the report/question.
I think the reason here is that sql.Date extends util.Date so it was found OK
not to narrow the type. You can still cast it to util.Date without issues.
> JdbcDataSet returning java.sql.Date instead of java.util.Date
> -------------------------------------------------------------
>
> Key: METAMODEL-169
> URL: https://issues.apache.org/jira/browse/METAMODEL-169
> Project: Apache MetaModel
> Issue Type: Bug
> Environment: MySQL
> Reporter: Tanner Hobson
> Priority: Minor
>
> I'm not sure if this really counts as a bug or if it is intentional.
> When using any DataSet, I would expect that getting a value with a SelectItem
> type of ColumnType.DATE would result in a java.util.Date (which is also what
> getJavaEquivalentClass() returns), but the JdbcDataSet returns a
> java.sql.Date.
> This happens because JdbcDataSet.getValue() returns the value of
> ResultSet.getDate(), which is a java.sql.Date.
> To be consistent with getJavaEquivalentClass(), it would be helpful to
> convert it to a java.util.Date, unless there is some other reason why this
> method returns a java.sql.Date that I don't know.
> We could also add a flag which controls whether this transformation occurs or
> not, so that existing code doesn't break.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
