Re: JPA 2.2 java.time type support for primary keys?

Steve Ebersole
 

I agree that this seems like an oversight to a degree.  Some of the new java.time types should be allowed for versions and others for ids, but not the complete list (imo).  Because the new java.time contracts are already more rich, I think that the TemporalType restrictions are better handled by allowing discrete set of those types for id/version.  E.g. the implication of TemporalType.DATE in regards to id values is that the time portion makes the value a bad id value - but java.time already has a rich type to describe that (java.time.LocalDate, etc).

I doubt the spec gets changed for this MR, as we have been told previously that it is too late in the process to change/amend the spec... but I'd also expect providers will support the Java 8 types for ids and versions, it just would not be required by the spec.

FWIW, the only real discussion of supporting these temporal types was actually an email on the old "jpa spec users" mailing list with the subject "JPA_SPEC-63".

On Tue, Oct 17, 2017 at 3:00 PM Jody Grassel <jgrassel@...> wrote:

[Edited Message Follows]

While going through the JPA 2.2 spec and reading the following:

2.4 Primary Keys and Entity Identity
...
A simple primary key or a field or property of a composite primary key should be one of the following types: any Java primitive type; any primitive wrapper type; java.lang.String; java.util.Date; java.sql.Date; java.math.BigDecimal; java.math.BigInteger.[9] If the primary key is a composite primary key derived from the primary key of another entity, the primary key may contain an attribute whose type is that of the primary key of the referenced entity as described in Section 2.4.1. Entities whose primary keys use types other than these will not be portable.  If generated primary keys are used, only integral types will be portable. If java.util.Date is used as a primary key field or property, the temporal type should be specified as DATE.

Above, I've bold-faced all text that referred to temporal types.  Note that there was no mention of the java.time types that support for was introduced in JPA 2.2.  Is this an intended omission -- that java.time types are not permissible for use with @Id properties, or is a correction in the spec's language needed? 

Looking at the @Id javadoc at https://javaee.github.io/javaee-spec/javadocs/javax/persistence/Id.html it states:

Specifies the primary key of an entity. The field or property to which the Id annotation is applied should be one of the following types: any Java primitive type; any primitive wrapper type; String; java.util.Date; java.sql.Date; java.math.BigDecimal; java.math.BigInteger.

Again, it only mentions java.util.Date and java.sql.Date, and no mention of the java.time types.

It also looks like @Version also omits any use of the new type, as on https://javaee.github.io/javaee-spec/javadocs/javax/persistence/Version.html it states:

The following types are supported for version properties: int, Integer, short, Short, long, Long, java.sql.Timestamp.

With no mention of at least java.time.LocalDateTime which maps via JDBC Appendix B to TIMESTAMP.

Join jpa-spec@javaee.groups.io to automatically receive all group messages.