Hi Sanne,

Multi-release JARs sound promising. I'll forward your suggestion to the HANA 
JDBC driver team.


-----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


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

Reply via email to