Actually the JPA spec (1.0 and 2.0) has a knock-on effect concerning the use of
entity beans in the front-end.
Since I must use either java.util.Date or Calendar as the type for my temporal
properties, I can't rely on the property type to distinguish between times and
dates when it comes to displaying the values or for parsing incoming HTTP
parameters.
This gives the programmer extra coding burden in the front-end, and I can't see
any counter-balancing advantage in the persistence layer from banning the use of
java.sql.Date and Time.
Have I missed something or is this an improvement that should be put into JPA 2
before it goes final?
Adam Hardy on 04/03/09 23:54, wrote:
Thanks Mike.
Looks like the same wording in JPA 2.0 too.
Regards Adam
Michael Dick on 04/03/09 19:39, wrote:
Hi Adam,
Looks like we're less stringent about the @Temporal annotation. I'd have to
look closer to see that's the case.
Regarding the JPA 2.0 spec you can find a copy of the public review draft
here http://jcp.org/aboutJava/communityprocess/pr/jsr317/index.html
-mike
On Wed, Mar 4, 2009 at 10:57 AM, Adam Hardy
<[email protected]>wrote:
I converted my project over from java.util.Date to java.sql.Timestamp for
entity fields after I figured that would give me more room to maneuver
with a new requirement for time fields.
It went smoothly with OpenJPA and made the MVC layer's type converter
code a cinch to refactor.
However I then ran my tests under Hibernate JPA and Toplink Essentials,
and both complained bitterly that I was violating the spec and threw
exceptions.
Looking through the JPA 1 spec, I see where I have transgressed (9.1.20):
"The Temporal annotation must be specified for persistent fields or
properties of type java.util.Date and java.util.Calendar. It may only be
specified for fields or properties of these types."
Is the OpenJPA interpretations deliberately including Timestamp or is
that considered an OpenJPA feature?
Is there any change in JPA 2?
Also, can anyone give a URL for the JPA 2 spec pdf? Google turned up
nothing.
