Out of curiosity, do you have a link to this new java.sql.ShardingKey feature?
Other than that, I agree with Sanne - multiple jars (with proper classifier once y'all publish your drivers) is the best option On Mon, Mar 12, 2018 at 11:35 AM Bregler, Jonathan <jonathan.breg...@sap.com> wrote: > Hi Sanne, > > Multi-release JARs sound promising. I'll forward your suggestion to the > HANA JDBC driver team. > > Thanks, > Jonathan > > -----Original Message----- > From: sanne.grinov...@gmail.com [mailto:sanne.grinov...@gmail.com] On > Behalf Of Sanne Grinovero > Sent: Monday, March 12, 2018 4:45 PM > To: Bregler, Jonathan <jonathan.breg...@sap.com> > Cc: hibernate-dev@lists.jboss.org > Subject: Re: [hibernate-dev] Hibernate support for JDBC drivers targeting > multiple JVM versions > > Hi Jonathan, > > personally this looks like an issue with the driver as class > initialization could be triggered by a number of things, it's going to > be hard to dodge them all, not least all containers and servers have > their own peculiarities in how they load and wrap drivers and > datasources; could you suggest the HANA JDBC team to release > multi-release jars? That would be safer, and also avoid issues with > other tools beyond Hibernate ORM. > - http://openjdk.java.net/jeps/238 > > Thanks, > Sanne > > On 12 March 2018 at 15:27, Bregler, Jonathan <jonathan.breg...@sap.com> > wrote: > > Hi, > > > > in a recent version of the HANA JDBC driver the new JDBC 4.3 features > that came with Java 9 have been implemented. The driver itself is still > compiled for Java 7 (javac -target 1.7). So the driver should also be > usable with a JVM 7 or 8. This works as expected until Java reflection is > used to determine, for example, the existence of a method on the connection > class. Hibernate uses this approach in > org.hibernate.engine.jdbc.env.internal.DefaultSchemaNameResolver#determineAppropriateResolverDelegate > to determine if the connection class implements the #getSchema method. In > this case the JVM tries to load the entire connection class including the > non-existing new interface java.sql.ShardingKey. The result is a > java.lang.NoClassDefFoundError being thrown which isn't caught anywhere > causing the Hibernate bootstrapping process to fail. I've attached a sample > stack trace to this mail. > > > > Situations like this can also occur in other places, for example, when > getting a connection from a Hikari connection pool. > > > > My question is now how you think Hibernate should handle situations like > this. Do you see it as a JDBC driver issue? Should Hibernate ignore the > error and continue with a conservative guess if possible (e.g. assume that > the connection class doesn't implement #getSchema)? > > > > Thanks, > > Jonathan > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev