java.util.Date format output changes when migrating from hibernate-4 to hibernate-5

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.

The issue was still @Temporal not being honored between Hibernate-5 and JPA 2.2, so the mapping disappeared. I had a faux DTO returning the data and forced a formatter on that particular field, which seems to have fixed the issue.