Java 8 brought lots of great features and one of the most important and most anticipated ones was the new Date and Time API. There were lots of issues with the old API and I won’t get into any details on why we needed a new one. I’m sure you had to struggle often enough with it yourself.
All these issues are gone with Java 8. The new Date and Time API is well designed, easy to use and (finally) immutable. The only issue that remains is, that you cannot use it with JPA.
Well, that’s not completely correct. You can use it, but JPA will map it to a BLOB instead of a DATE or TIMESTAMP. That means the database is not aware of the date object and cannot apply any optimization for it. That’s not the way we should or want to do it.
But that doesn’t mean that you can’t use the Date and Time API. You just have to decide how you want to add the support for it. You either use Hibernate 5, which provides proprietary support for the Date and Time API, or you take a few minutes to implement an AttributeConverter like I show you in this post.
Don’t want to read? Watch it here!
Follow me on YouTube to not miss any new videos.
Why does JPA not support LocalDate and LocalDateTime?
The answer is simple, JPA 2.1 was released before Java 8 and the Date and Time API simply didn’t exist at that point in time. Therefore the @Temporal annotation can only be applied to attributes of type java.util.Date and java.util.Calendar.
If you want to store a LocalDate attribute in a DATE column or a LocalDateTime in a TIMESTAMP column, you need to define the mapping to java.sql.Date or java.sql.Timestamp yourself. Thanks to the attribute converter, one of several new features in JPA 2.1, this can be achieved with just a few lines of code.
In the following examples, I will show you how to create an attribute converter for LocalDate and LocalDateTime. If you want to learn more about attribute converter, have a look at How to implement a JPA 2.1 Attribute Converter or one of the other usage examples like a better way to persist enums or encrypting data.
The most important things you need to remember about attribute converter are also described in the free “New Features in JPA 2.1” cheat sheet.
The example
Before we create the attribute converters, lets have a look at the example entity for this post.
Attribute converter are part of the JPA 2.1 specification and can therefore be used with any JPA 2.1 implementation, e.g. Hibernate or EclipseLink. I used Wildfly 8.2 with Hibernate 4.3 for the following examples.
Converting LocalDate
As you can see in the following code snippet, there isn’t much you need to do to create an attribute converter for LocalDate.
You need to implement the AttributeConverter<LocalDate, Date> interface with its two methods convertToDatabaseColumn and convertToEntityAttribute. As you can see on the method names, one of them defines the conversion from the type of the entity attribute (LocalDate) to the database column type (Date) and the other one the inverse conversion. The conversion itself is very simple because java.sql.Date already provides the methods to do the conversion to and from a LocalDate.
Additionally the attribute converter needs to be annotated with the @Converter annotation. Due to the optional autoApply=true property, the converter will be applied to all attributes of type LocalDate. Have a look here, if you want to define the usage of the converter for each attribute individually.
The conversion of the attribute is transparent to the developer and the LocalDate attribute can be used as any other entity attribute. You can use it as a query parameter for example.
Converting LocalDateTime
The attribute converter for LocalDateTime is basically the same. You need to implement the AttributeConverter<LocalDateTime, Timestamp> interface and the converter needs to be annotated with the @Converter annotation. Similar to the LocalDateConverter, the conversion between a LocalDateTime and an java.sql.Timestamp is done with the conversion methods of Timestamp.
Conclusion
JPA 2.1 was released before Java 8 and therefore doesn’t support the new Date and Time API. If you want to use the new classes (in the right way), you need to define the conversion to java.sql.Date and java.sql.Timestamp yourself. This can be easily done by implementing the AttributeConverter<EntityType, DatabaseType> interface and annotating the class with @Converter(autoApply=true). By setting autoApply=true, the converter will be applied to all attributes of the EntityType and no changes on the entity are required.
As far as I know, the next JPA release will support the Date and Time API and the different implementations will probably support it even earlier. Hibernate 5 for example will support it as a proprietary feature.
If you want to learn more about the new features in JPA 2.1, have a look at the JPA 2.1 Overview and get your free “New Features in JPA 2.1” cheat sheet.
Binh Thanh Nguyen says
Thanks, nice tips
Caleb Cushing says
or you can upgrade to hibernate 5 and the hibernate-java8 library… support is coming, kind of like winter
Thorben Janssen says
Yes, Hibernate 5 provides support for the Date and Time API but there are lots of projects that will not switch to the new Hibernate for quite some time and this post was written before Hibernate 5.0.0.Final was released.
So, if you cannot use Hibernate 5, writing your own AttributeConverter is a quick and easy way to get support for LocalDate and LocalDateTime.
Bernd Müller says
Works only sometimes, because not null safe.
Should be:
public class LocalDateConverter implements AttributeConverter {
@Override
public Date convertToDatabaseColumn(LocalDate date) {
return (date == null ? null : Date.valueOf(date));
}
@Override
public LocalDate convertToEntityAttribute(Date date) {
return (date == null ? null : date.toLocalDate());
}
}
Regards
Bernd
Thorben Janssen says
Fixed it.
Thanks!
Thorben
Moody Salem says
Wondering how Hibernate scans for @Converter annotated classes, because I have these converters in a JAR included into my project and autoApply does not work.
Thorben Janssen says
Did you add the converter JAR to your persistence.xml?
…
../lib/converter.jar
e.g.
…
I didn’t try it out, but if the converter.jar is referenced in the persistence.xml, Hibernate should find the Converter.
highdali says
awesome
Justyna says
Thanks a lot! This article is the answer for problem (LocalDate) in my project! I’ll return here yet!
Thorben Janssen says
You’re welcome 🙂
Sathish Kumar says
Hello Thorben, Awesome writing. Thank you for the post.
I would like to have some clarification on using LocalDate in a Serializable class. Since its a value based object, Sonar throws me an error saying “Value based objects should not be serialized”. If my requirement is to have a LocalDate field in a JSF managed bean with SessionScoped, then how would I handle it? Kindly requesting your inputs.
Thank you in advance!
Thorben Janssen says
Hi Sathish,
that’s a complex topic. Here’s an interesting discussion about it: https://groups.google.com/forum/#!topic/sonarqube/WZh_rrh_Avk
Regards,
Thorben
Sathish Kumar says
Dear Thorben,
Thank you very much for your reply 🙂
Regards,
Sathish
Nick G says
There’s a class: org.springframework.data.jpa.convert.threeten.Jsr310JpaConverters that seems to do exactly this. I actually implemented the converters per this article, but then as I was digging through the dependency code I found this class, commented out everything in the Converter classes and I am still able to defined LocalDate, LocalDateTime fields in my entity classes and they get persisted and read correctly (MariaDB).
Looks like Spring Data is getting close to implementing JPA 2.1, so it may not matter much longer, but I wanted to comment on an otherwise great article by a great blogger.. keep up the good work T.J.!
Thorben Janssen says
Thanks Nick!
Yes, Spring Data provides similar AttributeConverter for the Date and Time API.
And if you use JPA 2.2 or Hibernate 5, you don’t even need any AttributeConverter. So, as soon as all projects are updated, we will no longer need this workaround.
Grant says
I am having a problem with this. The date values in my database are being stored 1 day behind.
I have figured out the cause, but not sure how to fix.
My application is running in local time (GMT+1), database is MySQL in UTC, and using the useLegacyDatetimeCode=false connection property.
LocalDate only has concept of year, month and day (not time). The Date.valueOf(locDate) imposes an interpretation of local time zone when creating the Date object, which leads to date in database being wrong when stored (and also when retrieved).
Any thoughts on how to fix this cleanly? I am only trying to store a date of birth so hoping to be time and timezone agnostic 🙂
Thanks.
Thorben Janssen says
Hi Grant,
The best way to fix these kinds of issues is to use the same timezone for your application and your database. Using different timezones can cause so many issues, that it’s not worth your time and effort to try to fix all of them.
Regards,
Thorben