[hibernate-dev] Hibernate support for JDBC drivers targeting multiple JVM versions

[Steve Ebersole]

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.bregler at 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.grinovero at gmail.com [mailto:sanne.grinovero at gmail.com] On
> Behalf Of Sanne Grinovero
> Sent: Monday, March 12, 2018 4:45 PM
> To: Bregler, Jonathan <jonathan.bregler at sap.com>
> Cc: hibernate-dev at 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.bregler at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>