Description
jdbc-v2
Steps to reproduce
1.Upgrading from jdbcv2 version 0.9.4 to 0.9.8
2.Start the Java program
Error Log or Exception StackTrace
2026-07-24 16:18:00.404 ERROR 650071 --- [ scheduling-1] o.s.s.s.TaskUtils$LoggingErrorHandler : Unexpected error occurred in scheduled task
java.lang.NoSuchMethodError: java.net.URLDecoder.decode(Ljava/lang/String;Ljava/nio/charset/Charset;)Ljava/lang/String;
at com.clickhouse.jdbc.internal.JdbcConfiguration.parseUrl(JdbcConfiguration.java:226) ~[jdbc-v2-0.9.8.jar!/:jdbc-v2 0.9.8 (revision: 8a3e33a)]
at com.clickhouse.jdbc.internal.JdbcConfiguration.<init>(JdbcConfiguration.java:90) ~[jdbc-v2-0.9.8.jar!/:jdbc-v2 0.9.8 (revision: 8a3e33a)]
at com.clickhouse.jdbc.ConnectionImpl.<init>(ConnectionImpl.java:76) ~[jdbc-v2-0.9.8.jar!/:jdbc-v2 0.9.8 (revision: 8a3e33a)]
at com.clickhouse.jdbc.Driver.connect(Driver.java:109) ~[jdbc-v2-0.9.8.jar!/:jdbc-v2 0.9.8 (revision: 8a3e33a)]
at com.alibaba.druid.pool.DruidAbstractDataSource.createPhysicalConnection(DruidAbstractDataSource.java:1700) ~[druid-1.2.15.jar!/:na]
at com.alibaba.druid.pool.DruidAbstractDataSource.createPhysicalConnection(DruidAbstractDataSource.java:1792) ~[druid-1.2.15.jar!/:na]
at com.alibaba.druid.pool.DruidDataSource.init(DruidDataSource.java:914) ~[druid-1.2.15.jar!/:na]
at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:1433) ~[druid-1.2.15.jar!/:na]
at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:1429) ~[druid-1.2.15.jar!/:na]
at com.alibaba.druid.pool.DruidDataSource.getConnection(DruidDataSource.java:80) ~[druid-1.2.15.jar!/:na]
at org.springframework.jdbc.datasource.DataSourceUtils.fetchConnection(DataSourceUtils.java:159) ~[spring-jdbc-5.3.20.jar!/:5.3.20]
at org.springframework.jdbc.datasource.DataSourceUtils.doGetConnection(DataSourceUtils.java:117) ~[spring-jdbc-5.3.20.jar!/:5.3.20]
at org.springframework.jdbc.datasource.DataSourceUtils.getConnection(DataSourceUtils.java:80) ~[spring-jdbc-5.3.20.jar!/:5.3.20]
at org.mybatis.spring.transaction.SpringManagedTransaction.openConnection(SpringManagedTransaction.java:80) ~[mybatis-spring-2.0.7.jar!/:2.0.7]
at org.mybatis.spring.transaction.SpringManagedTransaction.getConnection(SpringManagedTransaction.java:67) ~[mybatis-spring-2.0.7.jar!/:2.0.7]
at org.apache.ibatis.executor.BaseExecutor.getConnection(BaseExecutor.java:337) ~[mybatis-3.5.10.jar!/:3.5.10]
at org.apache.ibatis.executor.SimpleExecutor.prepareStatement(SimpleExecutor.java:86) ~[mybatis-3.5.10.jar!/:3.5.10]
Expected Behaviour
In the official documentation, the Java runtime environment for JDBC has always been openjdk >= 1.8. However, starting from the version 0.9.7 of jdbcv2, I found that the default used openjdk version is higher than 1.8. The parameter for URLDecoder.decode originally in openjdk 1.8 was String decode(String s, String enc), but now the parameter for URLDecoder.decode is String decode(String s, Charset charset), and the second parameter type is Charset. This causes users using openjdk 1.8 version to encounter a problem of incorrect parameter type when relying on jdbcv2 versions 0.9.7 or above.
Code Example
JdbcConfiguration#parseUrl: 209-213, jdbcv2 version is 0.9.4
if (uri.getQuery() != null && !uri.getQuery().trim().isEmpty()) {
for (String pair : uri.getRawQuery().split("&")) {
try {
String[] p = pair.split("=", 2);
if (p.length != 2 || p[0] == null || p[1] == null) {
throw new SQLException("Invalid query parameter '" + pair + "'");
}
String key = URLDecoder.decode(p[0], StandardCharsets.UTF_8.name());
if (key == null || key.trim().isEmpty() || !PATTERN_HTTP_TOKEN.matcher(key).matches()) {
throw new SQLException("Invalid query parameter key in pair'" + pair + "'");
}
String value = URLDecoder.decode(p[1], StandardCharsets.UTF_8.name());
if (value == null || value.trim().isEmpty() || "=".equals(value)) {
throw new SQLException("Invalid query parameter value in pair '" + pair + "'");
}
properties.put(key.trim(), value);
} catch (UnsupportedEncodingException e) {
throw new SQLException("Internal error'", e);
}
}
}
The parameter passed to URLDecoder.decode is (String, String)
JdbcConfiguration#parseUrl:222-226,jdbcv2版本为0.9.8
if (rawPath != null && !rawPath.trim().isEmpty() && !"/".equals(rawPath)) {
// Remove leading slash for processing
String pathWithoutLeadingSlash = rawPath.startsWith("/") ? rawPath.substring(1) : rawPath;
int lastSlashIndex = pathWithoutLeadingSlash.lastIndexOf('/');
if (lastSlashIndex > 0) {
httpPath = "/" + pathWithoutLeadingSlash.substring(0, lastSlashIndex);
database = URLDecoder.decode(pathWithoutLeadingSlash.substring(lastSlashIndex + 1), StandardCharsets.UTF_8);
} else {
// No slash found (lastSlashIndex == -1), so it's a single segment representing the database name.
// Example: "mydb" -> httpPath="", database="mydb"
database = URLDecoder.decode(pathWithoutLeadingSlash, StandardCharsets.UTF_8);
}
}
The type of the parameter passed to URLDecoder.decode is (String, Charset).
Configuration
Client Configuration
Environment
ClickHouse Server
- ClickHouse Server version: 25.3.2.39
- ClickHouse Server non-default settings, if any:
CREATE TABLE statements for tables involved:
- Sample data for all these tables, use clickhouse-obfuscator if necessary
Description
jdbc-v2
Steps to reproduce
1.Upgrading from jdbcv2 version 0.9.4 to 0.9.8
2.Start the Java program
Error Log or Exception StackTrace
Expected Behaviour
In the official documentation, the Java runtime environment for JDBC has always been openjdk >= 1.8. However, starting from the version 0.9.7 of jdbcv2, I found that the default used openjdk version is higher than 1.8. The parameter for URLDecoder.decode originally in openjdk 1.8 was String decode(String s, String enc), but now the parameter for URLDecoder.decode is String decode(String s, Charset charset), and the second parameter type is Charset. This causes users using openjdk 1.8 version to encounter a problem of incorrect parameter type when relying on jdbcv2 versions 0.9.7 or above.
Code Example
Configuration
Client Configuration
Environment
ClickHouse Server
CREATE TABLEstatements for tables involved: