I am currently trying to update some of our current libraries, and I've hit a blocking issue. This is a legacy application, here's the basic setup:
Java 8
Tomcat 7
Mysql 5.5.27-28.1-log Percona Server
Spring 4.2.4.RELEASE
The Relevant Hibernate versions are here:
55:HIBERNATE_VERSION = "4.3.11.Final"
236: "org.hibernate:hibernate-core:jar:#{HIBERNATE_VERSION}",
239: "org.hibernate:hibernate-envers:jar:#{HIBERNATE_VERSION}",
241: "org.hibernate:hibernate-entitymanager:jar:#{HIBERNATE_VERSION}",
The updated version is:
HIBERNATE_VERSION = "5.2.12.Final"
I'll spare you the details, but there are quite a few other dependencies. I gradually eliminated every other change (including the related spring update), but the above listed libraries are the only 3 that are changing.
Now, one of the front-end clients are choking because the date format had changed.
Under hibernate-4, it looks like:
createdDate: "2014-09-15",
With the above changes, it now looks like this:
createdDate: 1410753600000,
The class annotations look like this:
@Temporal(TemporalType.DATE)
@Column(columnDefinition="datetime")
private Date createdDate;
The table schema is on mysql and its listed as this:
| createdDate | datetime | YES | MUL | NULL | |
Where "Date" is a java.util.Date. Yes, I understand java.util.Date is horrible. I also know that @Temporal was lagging behind java 8 and the new features. We use jodatime and will be looking to standardize on the new J8 conventions, but this is an old application and this is a central table on an even older database.
I've tried a number of solutions including:
- consolidating dependencies
- isolating dependencies (where we are now)
- implementing a @Converter globally (breaks other specific date formats)
- using said @Converter on only the field (still getting epoch time)
- using the outputting json mapper to set the field (breaks because every time/date ends up having that format)
- converting the base type to java.sql.Date (as that's what Temporal did).
From checking the change logs, I can't find anything that would explain this particular change, let alone any reason default behavior would change so drastically. I understand that a larger migration can help, but I'm really just looking to use the old default behavior so I can straighten out the rest of my upgrades without having them wrapped up in major code/db changes.
Any ideas here? I've upgraded hibernate many times before and never encountered a problem quite like this.
