JPA 2.1: Introducing Java 8 Date/Time API

Question

I'd like to add support for the Java 8 Date/Time API (JSR-310) in my JPA-enabled application.

It's clear that JPA 2.1 does not support the Java 8 Date/Time API.
As a workaround, the most common advise is to use an AttributeConverter.

In my existing application, I changed my entities to use LocalDate/LocalDateTime types for the column mapping fields and added legacy setter/getters for java.util.Date to them.
I created corresponding AttributeConverter classes.

My application does now fail when using Query.setParameter() with java.util.Date instances (it worked before the transition to the new API).
It seems that JPA expects the new date types and does not convert it on the fly.

I expected that if passing an argument to setParameter() of a type for which an AttributeConverter has been registered, it would be automatically converted by the converter. But this seems to be not the case, at least not using EclipseLink 2.6.2:

java.lang.IllegalArgumentException: You have attempted to set a value of type class java.util.Date for parameter closeDate with expected type of class java.time.LocalDate from query string SELECT obj FROM [...]
    at org.eclipse.persistence.internal.jpa.QueryImpl.setParameterInternal(QueryImpl.java:937) ~[eclipselink-2.6.2.jar:2.6.2.v20151217-774c696]
    at org.eclipse.persistence.internal.jpa.EJBQueryImpl.setParameter(EJBQueryImpl.java:593) ~[eclipselink-2.6.2.jar:2.6.2.v20151217-774c696]
    at org.eclipse.persistence.internal.jpa.EJBQueryImpl.setParameter(EJBQueryImpl.java:1) ~[eclipselink-2.6.2.jar:2.6.2.v20151217-774c696]
  [...]

Questions:

Is this behavior expected? Did I miss something?
Is there a way to use the new date types as fields without breaking existing code?
How did you deal with the transition to the new Date/Time API within JPA?

UPDATE:

However, It seems that at least using EclipseLink, custom types for which an AttributeConverter exists, are not fully supported:

Within JPQL queries, neither the actual field type nor the converted database type can be used as a parameter. When using the converted database type, the exception described above occurs. When using the actual field type (e.g. LocalDate), it's directly passed to the jdbc driver which doesn't know this type:

Caused by: java.sql.SQLException: Invalid column type
    at oracle.jdbc.driver.OraclePreparedStatement.setObjectCritical(OraclePreparedStatement.java:10495) 
    at oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:9974) 
    at oracle.jdbc.driver.OraclePreparedStatement.setObjectInternal(OraclePreparedStatement.java:10799) 
    at oracle.jdbc.driver.OraclePreparedStatement.setObject(OraclePreparedStatement.java:10776) 
    at oracle.jdbc.driver.OraclePreparedStatementWrapper.setObject(OraclePreparedStatementWrapper.java:241)
    at org.eclipse.persistence.internal.databaseaccess.DatabasePlatform.setParameterValueInDatabaseCall(DatabasePlatform.java:2506)

I would expect that EclipseLink converts the field type to the java.sql type using the AttributeConverter. (see also this bug report: https://bugs.eclipse.org/bugs/show_bug.cgi?id=494999 )

Which leads us to the most important question #4:

Is there a workaround/solution to support java 8 date fields using EclipseLink, including the possibility to use a query parameters on such a field?

ADDITIONAL INFO

I don't know JPA, but why use, say, java.util.Date instead of java.sql.Date? The sql* types have been retrofitted to convert from/to JSR 310 types — fge, May 11 '16 at 15:19
I believe for now you need to add another dependency to get Java 8 support in Hibernate. The removes the need for you to specify AttributeConverters around Data/Time classes. See:http://stackoverflow.com/a/37098160/1356423 — Alan Hay, May 11 '16 at 15:23
What's your code for the converter and the actual query with parameter? — Steffen Harbich, Jun 06 '16 at 08:34
@SteffenHarbich I've updated the question, now providing converted code and query — MRalwasser, Jun 06 '16 at 12:59
MRalwasser, there are differences to [my entity and converter implementation](http://stackoverflow.com/a/37628540/1063673). You could try to change your code according to mine, to test whether it makes any difference. My converter uses Timestamp as DB data type and the @Temporal annotation is not required. — Steffen Harbich, Jun 06 '16 at 15:21
@SteffenHarbich This pushed me one step further - thank you. It seems that the target type of the `AttributeConverter` needs to be a `java.sql` type (despite the fact that `java.util.Date` works perfectly as an entity field). Simple queries do now work. However, when using the same parameter more than once within a query, EclipseLink seems to not convert the value after the first occurrence, resulting in the exception described above. Adjusting your query to `"SELECT p FROM MeasuringPoint p WHERE p.when = :custDate AND p.when = :custDate"` should reproduce this. — MRalwasser, Jun 07 '16 at 16:57
I tried it and works as expected, no error. Did you change the parameter value from Date to LocalDateTime? Maybe post your code. — Steffen Harbich, Jun 07 '16 at 19:58
@SteffenHarbich Can you try the query `SELECT p FROM MeasuringPoint p WHERE p.when = :custDate AND p.when -1 = :custDate`? — MRalwasser, Jun 08 '16 at 08:13
What is the intention of "-1" in the query? I would guess it is not valid JPQL. — Steffen Harbich, Jun 08 '16 at 09:00
It should substract a day from p.when before comparing it to the parameter. But the -1 does not really matter. Any JPQL which uses :custDate for another time (in a different expression as the first usage) should reproduce the exception. — MRalwasser, Jun 08 '16 at 11:31
Strange. At least there is the work-around of using another parameter name with the same value for the second occurrence. — Steffen Harbich, Jun 09 '16 at 06:22
The -1 in the query brings up a syntax exception when I execute it. — Steffen Harbich, Jun 09 '16 at 16:10

score 4 · Answer 1 · answered May 11 '16 at 15:23

4

Some time ago, I converted a Java EE 7 web app from Java 7 to Java 8, and replaced java.util.Date in entities with LocalDate and LocalDateTime.

Yes, that behavior is expected, because an AttributeConverter only converts between the type used for entity fields and the database type (ie, java.sql.Date, etc.); it does not convert between an entity field type and a java.util.Date used in a query parameter.
As far as I know, no, there is no way to continue using java.util.Date in existing code, after introducing the java.time types into JPA entities.
Besides creating the necessary AttributeConverter implementations, I changed all occurrences of java.util.Date to the appropriate java.time types, not only in entities but also in JPA-QL queries and in business methods.

For item 2, of course you can go some way by using utility methods and getters/setters that convert between java.util and java.time, but it's not going to go all the way. More importantly, I don't quite see the point of introducing java.time types into JPA entity attributes, if you are not willing to convert the remaining code that uses these attributes. After the conversion work I did in that Java EE app, there were no uses of java.util.Date left anywhere (though I also had to create converters for JSF).

answered May 11 '16 at 15:23

Rogério

16,171
2
50
63

Regarding 1: I've updated the question, citing the JPA 2.1 spec. – MRalwasser May 11 '16 at 15:30
I'm talking about a fairly large code base. I wish I could yet migrate to the new API all at once. Unfortunately, budget and time does not allow this for now. I'd like to support the new API in the entities which would encourage our team to use it for future tasks and during refactoring of existing code. At some break-even point, we'll do the complete transition. – MRalwasser May 11 '16 at 15:45
1

JDBC drivers only understand `java.sql` types, not `java.util.Date`. So, the JPA converters are only between `java.time` and `java.sql` types (at least in my case, they were); they won't convert a `java.time.LocalDate` to a `java.util.Date` and then to a `java.sql.Date` (which in turn gets mapped to a native database `DATE` type). – Rogério May 11 '16 at 15:54
l don't think JDBC plays a role in my question at all. We're using java.util.Date fields in our JPA entities since many years, EclipseLink cares about talking to the JDBC driver (and a conversion to java.sql.Date). My question is just about AttributeConverter, (expected) conversion within JPQL and alternatives to my approach. – MRalwasser May 11 '16 at 16:00
Regarding 2: At least when using eclipselink, using the java.time types as query parameters will fail, too (see also https://bugs.eclipse.org/bugs/show_bug.cgi?id=494999 ). So I can neither use the java.util.Date nor the new types as query parameters. How did you resolve this issue? – MRalwasser May 31 '16 at 11:50

score 2 · Answer 2 · answered Jun 02 '16 at 15:11

With so many bugs in the provider itself I don't think you have much choice but to use java.util.Date on the mapping level and java 8 dates on the API level.

Assuming you write a utility class for conversion to/from java.util dates called DateUtils, you could define your mappings as follows:

@Entity
public class MyEntity {

  @Column("DATE")
  private Date date; // java.util.Date

  public void setDate(LocalDateTime date) {
    this.date = DateUtils.convertToDate(date);
  }

  public LocalDateTime getDate() {
    return DateUtils.convertFromDate(date);
  }
}

Then to filter by date in JPQL:

public List<MyEntity> readByDateGreaterThan(LocalDateTime date) {
  Query query = em.createQuery("select e from MyEntity e where e.date > :date");
  query.setParameter("date", DateTuils.convertToDate(date));
  return query.getResultList();
}

So, java.util dates would be used in entities and DAOs (Repositories) internally, while the API exposed by entities and DAOs would take/return java 8 dates, thus enabling the rest of the application to operate with java 8 dates only.

That's more or less what we're doing today. One drawback with that way is that the JPQL Parameters need to be converted to `java.util` types beforehand. — MRalwasser, Jun 07 '16 at 15:43

score 2 · Answer 3 · edited May 23 '17 at 10:29

I have the following setup:

EclipseLink v2.6.2
h2 Database v1.4.191
Java 8

The entity class is like:

@Entity
public class MeasuringPoint extends BaseEntity {

    @Column(nullable = false)
    private LocalDateTime when;

    public void setWhen(LocalDateTime when) {
        this.when = when;
    }

    public LocalDateTime getWhen() {
        return when;
    }

}

The required converter for JPA 2.1 is:

@Converter(autoApply = true)
public class LocalDateTimeConverter implements AttributeConverter<LocalDateTime, Timestamp> {

    @Override
    public Timestamp convertToDatabaseColumn(LocalDateTime attribute) {
        return attribute == null ? null : Timestamp.valueOf(attribute);
    }

    @Override
    public LocalDateTime convertToEntityAttribute(Timestamp dbData) {
        return dbData == null ? null : dbData.toLocalDateTime();
    }

}

Now I can make a query

List<?> result = em.createQuery(
         "SELECT p FROM MeasuringPoint p WHERE p.when = :custDate")
         .setParameter("custDate", LocalDateTime.now())
         .getResultList();

and it works like a charm. The result contains the expected entities. The conversion to TIMESTAMP is done automatically. When you have queries using the Criteria API, have a look at this answer which shows how to use LocalDateTime within Criteria API queries.

I wonder why it doesn't work with your code. Maybe the H2 JDBC driver does support something your Oracle doesn't.

score 0 · Answer 4 · answered May 11 '16 at 16:36

AttributeConverter is working as designed, as the converter is meant to handle the back and forth between your entity type and the database type. Validation is verifying the type of the parameter doesn't match the type within the entity - just because your attribute converter can handle it, doesn't mean it fits the contract of the attribute converter types. JPA only says it will go through the converter before going to the database, and in this case it doesn't go to the database.

If you don't like Rogério's suggestions, you can 1) modify the EclipseLink code to relax the validation to allow it to go through to your converter, or 2) change your attribute type to 'Object' instead so that all parameter types you may pass in will go to your converter.

JPA 2.1: Introducing Java 8 Date/Time API

4 Answers4

Linked