See https://github.com/brettwooldridge/HikariCP/issues/701#issuecomment-240415748

Comment From: philwebb

keywords for search: driver jdbc url

Comment From: philwebb

We're worried that this would cause side effects or break existing users.

Comment From: nmck257

I'd like to re-raise this for consideration. The JDK DriverManager model seems well-established for this exact purpose, and HikariCP has been using it successfully for years.

Previous comments on this issue were brief; do we recall more-specific potential side effects? From my perspective, the effort of the change would be small, and the breaking change in behavior doesn't seem unreasonable for a future release line upgrade.

Comment From: wilkinsona

In the 8 years since Brett's comment, the hypothetical concern that it raises hasn't, to our knowledge, been a problem. As such, with no known benefits to changing, it's very hard to justify doing so.

Comment From: nmck257

In search of benefits, let me post a use case. Consider a custom JDBC Driver which does take care to use a custom JDBC URL, such as the AWS SecretsManager drivers. This Baeldung article shows typical config: https://www.baeldung.com/spring-boot-integrate-aws-secrets-manager#2-spring-boot-application-integration-1

ie:

spring.datasource.driver-class-name=com.amazonaws.secretsmanager.sql.AWSSecretsManagerMySQLDriver
spring.jpa.database-platform=org.hibernate.dialect.MySQLDialect
spring.datasource.url=jdbc-secretsmanager:mysql://db-1.cwhqvgjbpgfw.eu-central-1.rds.amazonaws.com:3306
spring.datasource.username=rds/credentials

A developer might expect to be able to remove the driver class property, but, that yields this:

***************************
APPLICATION FAILED TO START
***************************

Description:

Failed to configure a DataSource: no embedded datasource could be configured.

Reason: Failed to determine a suitable driver class


Action:

Consider the following:
    If you want an embedded database (H2, HSQL or Derby), please put it on the classpath.
    If you have database settings to be loaded from a particular profile you may need to activate it (no profiles are currently active).

...or if h2 is on the classpath:

java.lang.RuntimeException: Driver org.h2.Driver claims to not accept jdbcUrl, jdbc-secretsmanager:mysql://db-1.cwhqvgjbpgfw.eu-central-1.rds.amazonaws.com:3306
    at com.zaxxer.hikari.util.DriverDataSource.<init>(DriverDataSource.java:109) ~[HikariCP-5.1.0.jar:na]
    at com.zaxxer.hikari.pool.PoolBase.initializeDataSource(PoolBase.java:327) ~[HikariCP-5.1.0.jar:na]
    at com.zaxxer.hikari.pool.PoolBase.<init>(PoolBase.java:113) ~[HikariCP-5.1.0.jar:na]
    at com.zaxxer.hikari.pool.HikariPool.<init>(HikariPool.java:91) ~[HikariCP-5.1.0.jar:na]
    at com.zaxxer.hikari.HikariDataSource.getConnection(HikariDataSource.java:111) ~[HikariCP-5.1.0.jar:na]
    at org.springframework.jdbc.datasource.DataSourceUtils.fetchConnection(DataSourceUtils.java:160) ~[spring-jdbc-6.1.10.jar:6.1.10]
[...]

The DataSource is being assembled as a Hikari data source, and Hikari has the logic to infer a driver class from the jdbcUrl, but, DataSourceConfiguration opts to infer the driver class itself and pass Hikari the resultant output from DataSourceBuilder as the base connection source for pooling. And that fails in this scenario.

Maybe there's an alternative solution here, where the autoconfig defers more of this setup logic to Hikari?

Comment From: wilkinsona

While Hikari's the default connection pool, we support others. As such, we can't always defer the setup logic to Hikari and I don't think we'd want to do so some of the time as the change in behavior when changing the connection pool would be confusing. I continue to believe that maintaining the status quo is the best option here.