People often ask me if we should upgrade to the latest Java version and I always answer the same thing. Of course we should, what could be wrong about better performance and the latest security updates? I always amend something about trying it in a test environment first, though. Over the years I have seldom seen any problems with a Java SE update, the platform is remarkably backwards compatible. But then magic entered the stage.
The magic in this case is the build time byte code enhancement performed by OpenJPA. Apparently the byte code verifier was changed a bit in Java SE 7, so the classes are no longer valid. Oracle’s JVM complains. IBM’s Java 7 implementation crashes spectacularly. With Java 6 it just works.
OpenJPA has always been my least favourite JPA implementation and this did nothing to change that. Oh, they have fixed the byte code enhancer in newer versions (but if you are stuck with an old application server that might not help), but a similar problem exists for Java SE 8 and who wants to bet on everything playing out with Java 9 and 10? Not me.
It also says something about IBM’s JDK. It really shouldn’t crash on an invalid class, simply reject it and move on.
Nevertheless, my recommendation is still to use the latest Java version, but again – test it first and if you are using OpenJPA and/or anything but Oracle’s mainstream JVM, test it well!
If you are using Hibernate 4.3 with JPA you may have seen the following warning:
WARN org.hibernate.ejb.HibernatePersistence HHH015016: Encountered a deprecated javax.persistence.spi.PersistenceProvider [org.hibernate.ejb.HibernatePersistence]; use [org.hibernate.jpa.HibernatePersistenceProvider] instead.
Fair enough, unfortunately it is difficult to get rid of it. Our persistence.xml already used the new provider:
<persistence-unit name="PU" transaction-type="RESOURCE_LOCAL"> <provider>org.hibernate.jpa.HibernatePersistenceProvider</provider> ... </persistence-unit>
What to do? It appears that this is a known bug, but as of 4.3.6.Final it is still open.
A convoluted workaround is to use custom code in order to create the correct persistence provider, as described here. Personally I prefer to wait for the fix as long as there are no test failures or other issues.