Hibernate support for Java 9 -
is hibernate ready work available builds of java 9?
i remember tried , failed. unfortunately don't remember specific cause.
by way, hibernate validator 5.2.3 works java 9.
i wondered same thing, , tried running hibernate app under access release of java 9. here's learned.
the first problem encountered classnotfoundexception javax.xml.bind.jaxbexception. jaxb has been in runtime classpath since java 6, in java 9 no longer published default. there @ least 2 ways can fix this:
- when run program in java 9 jvm, include command line argument "--add-modules java.se.ee". instructs java 9 include jaxb (and other libraries) in classpath again. keep in mind, argument rejected java 8 jvm; if allowing users run under more 1 version of java, you'll have compute command line dynamically, or require users edit command lines manually.
include jaxb library in application. if hibernate app annotation-driven, may not require implementation of jaxb, in case can away including jaxb api. here dependency added pom:
<!-- jaxb api --> <dependency> <groupid>javax.xml.bind</groupid> <artifactid>jaxb-api</artifactid> <version>2.2.11</version> </dependency>
with jaxb problem resolved, ran app , received several thousand lines of stack traces looked this:
java.lang.reflect.inaccessibleobjectexception: unable make protected final java.lang.class java.lang.classloader.defineclass(java.lang.string,byte[],int,int,java.security.protectiondomain) throws java.lang.classformaterror accessible: module java.base not "opens java.lang" unnamed module @49f97198 @ java.base/java.lang.reflect.accessibleobject.checkcansetaccessible(accessibleobject.java:337) @ java.base/java.lang.reflect.accessibleobject.checkcansetaccessible(accessibleobject.java:281) @ java.base/java.lang.reflect.method.checkcansetaccessible(method.java:197) @ java.base/java.lang.reflect.method.setaccessible(method.java:191) @ javassist.util.proxy.securityactions.setaccessible(securityactions.java:103) @ javassist.util.proxy.factoryhelper.toclass2(factoryhelper.java:181) @ javassist.util.proxy.factoryhelper.toclass(factoryhelper.java:164) @ javassist.util.proxy.proxyfactory.createclass3(proxyfactory.java:507) @ javassist.util.proxy.proxyfactory.createclass2(proxyfactory.java:492) @ javassist.util.proxy.proxyfactory.createclass1(proxyfactory.java:428) @ javassist.util.proxy.proxyfactory.createclass(proxyfactory.java:400) @ org.hibernate.proxy.pojo.javassist.javassistproxyfactory.postinstantiate(javassistproxyfactory.java:72) @ org.hibernate.tuple.entity.pojoentitytuplizer.buildproxyfactory(pojoentitytuplizer.java:162) @ org.hibernate.tuple.entity.abstractentitytuplizer.<init>(abstractentitytuplizer.java:163) @ org.hibernate.tuple.entity.pojoentitytuplizer.<init>(pojoentitytuplizer.java:58) after these exceptions, app may appear run normally. don't fooled: lazy initialization of objects has been disabled. may experience significant performance problems result.
these errors occurring because hibernate's runtime bytecode enhancement being blocked strong encapsulation rules in new module system. see this stackoverflow post great description of problem.
as noted in post, can eliminate these errors adding command line argument when launch jvm. approach workaround, , not long-term solution.
after trial , error, discovered better solution:
- use hibernate 5.0.0 or higher (earlier versions won't work), and
- request build-time bytecode enhancement (using gradle, maven, or ant plugins).
this avoids need hibernate perform javassist-based class modifications @ runtime, eliminating stack trace shown above. tested hibernate 5.0.12.final, 5.1.5.final, , 5.2.9.final.
however, should thoroughly test application afterward. bytecode changes applied hibernate @ build-time appear differ ones applied @ runtime, causing different application behavior. unit tests in app have succeeded years failed when enabled build-time bytecode enhancement. (i had chase down new lazyinitializationexception errors , other problems.) , behavior seems vary 1 version of hibernate another; fix unit tests work in 5.0.12, see them fail again in 5.1.5. proceed caution.
Comments
Post a Comment