apache/shardingsphere · error · SQLFeatureNotSupportedException
getDate(String columnLabel, Calendar cal)
Error message
getDate(String columnLabel, Calendar cal)
What it means
java.sql.SQLFeatureNotSupportedException thrown by the Apache ShardingSphere JDBC driver when ResultSet.getDate(String columnLabel, Calendar cal) is called on a DatabaseMetaData result set. Metadata calls such as Connection.getMetaData().getTables()/getColumns()/getIndexInfo()/getPrimaryKeys() on a jdbc:shardingsphere: URL return a synthesized DatabaseMetaDataResultSet that buffers every row as plain Java objects, so only scalar getters (getString, getInt, getBytes, single-arg getDate/getTime/getTimestamp, ...) are implemented. getDate(String columnLabel, Calendar cal) is declared final in AbstractUnsupportedDatabaseMetaDataResultSet and always throws, so this is a permanent, intentional limitation, not a version bug. Note that only the Calendar overloads are blocked; the single-argument rs.getDate(columnLabel) IS implemented and works. The driver materialized the underlying value once, so per-Calendar reinterpretation of a live driver value is not possible.
Source
Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedDatabaseMetaDataResultSet.java:126
@Override
public final Clob getClob(final int columnIndex) throws SQLException {
throw new SQLFeatureNotSupportedException("getClob");
}
@Override
public final Clob getClob(final String columnLabel) throws SQLException {
throw new SQLFeatureNotSupportedException("getClob");
}
@Override
public final Date getDate(final int columnIndex, final Calendar cal) throws SQLException {
throw new SQLFeatureNotSupportedException("getDate(int columnIndex, Calendar cal)");
}
@Override
public final Date getDate(final String columnLabel, final Calendar cal) throws SQLException {
throw new SQLFeatureNotSupportedException("getDate(String columnLabel, Calendar cal)");
}
@Override
public final Time getTime(final int columnIndex, final Calendar cal) throws SQLException {
throw new SQLFeatureNotSupportedException("getTime(int columnIndex, Calendar cal)");
}
@Override
public final Time getTime(final String columnLabel, final Calendar cal) throws SQLException {
throw new SQLFeatureNotSupportedException("getTime(String columnLabel, Calendar cal)");
}
@Override
public final Timestamp getTimestamp(final int columnIndex, final Calendar cal) throws SQLException {
throw new SQLFeatureNotSupportedException("getTime(int columnIndex, Calendar cal)");
}
@OverrideView on GitHub (pinned to e952770a21)
Solutions
- Replace the Calendar overload with the single-argument getter rs.getDate(columnLabel), which DatabaseMetaDataResultSet implements.
- If you needed the Calendar for timezone handling, do the conversion yourself: rs.getTimestamp(i) gives the value; use a SimpleDateFormat with TimeZone set, or java.time conversion, instead of the Calendar argument.
- If per-datasource timezone semantics matter, configure them on the underlying JDBC pools so values arrive already correct.
- If you do not control the calling code (third-party tool), run its metadata introspection against the physical datasource.
- Do not wait for a driver upgrade: only the Calendar overloads are blocked and that is by design.
Example fix
// before - Calendar overloads throw SQLFeatureNotSupportedException on ShardingSphere metadata result sets
Timestamp ts = metaDataRs.getTimestamp("REMARKS", Calendar.getInstance(TimeZone.getTimeZone("UTC")));
// after - single-argument getter is implemented; apply timezone yourself
Timestamp ts = metaDataRs.getTimestamp("REMARKS");
ZonedDateTime utc = ts == null ? null : ts.toInstant().atZone(ZoneOffset.UTC); Defensive patterns
Strategy: try-catch
Validate before calling
// Run BEFORE using exotic getters: detect a ShardingSphere-synthesized metadata ResultSet
static boolean isShardingSphereMetaDataResultSet(final ResultSet rs) {
return rs != null && "org.apache.shardingsphere.driver.jdbc.core.resultset.DatabaseMetaDataResultSet"
.equals(rs.getClass().getName());
}
static boolean supportsMetaDataGetter(final Connection c) throws SQLException {
// jdbc:shardingsphere: URLs return the synthesized metadata result set
return c != null && !c.getMetaData().getURL().startsWith("jdbc:shardingsphere:");
} Type guard
private static boolean isUnsupportedMetaDataResultSet(final ResultSet rs) {
return rs != null && rs.getClass().getName().startsWith("org.apache.shardingsphere.driver.jdbc.core.resultset.DatabaseMetaDataResultSet");
} Try / catch
try {
return rs.getDate(String columnLabel, Calendar cal);
} catch (final SQLFeatureNotSupportedException e) {
// ShardingSphere metadata result sets: fall back to the implemented scalar getter
final var v = rs.getDate(columnLabel);
} Prevention
- Never assume a JDBC driver implements every ResultSet getter; DatabaseMetaData results are the most commonly stubbed surface.
- When adding ShardingSphere in front of an existing datasource, smoke-test the metadata paths your frameworks use (getTables/getColumns loops) before shipping.
- Prefer the simplest getter (getString/getObject/getBytes) and convert in application code; it is portable across drivers.
- Treat SQLFeatureNotSupportedException (an SQLException subclass) as a signal about capability, not a transient failure - never retry it.
- Avoid Calendar-arg getters in shared code: several drivers and wrappers skip them; single-arg getters plus explicit timezone conversion are safer.
When it happens
Trigger: Calling getDate(String columnLabel, Calendar cal) on the ResultSet returned by ShardingSphereDatabaseMetaData, e.g. connection.getMetaData().getTables(null, null, "%", new String[]{"TABLE"}") followed by rs.getDate("TABLE_NAME", Calendar cal)) where connection was opened with the org.apache.shardingsphere.driver JDBC URL (jdbc:shardingsphere:classpath:sharding.yaml or jdbc:shardingsphere:...). Both the int-columnIndex and String-columnLabel overloads of every listed getter throw; the methods are final so no subclass can override them.
Common situations: Code that ran unchanged against the native MySQL/PostgreSQL/OpenGauss driver and is repointed to the ShardingSphere driver URL, so the same metadata loop now hits the stubbed getter; generic schema tooling that enumerates JDBC metadata with feature-rich getters (DBeaver, Squirrel SQL, Liquibase/Hibernate/Flyway schema validators, code generators, DBDiff tools); hand-written metadata loops that defensively call getWarnings()/clearWarnings() or use the Calendar overloads to pin a timezone. Calendar-arg getters are a common habit in multi-timezone services and in code copied from JDBC documentation examples.
Related errors
- getDate(int columnIndex, Calendar cal)
- getTime(int columnIndex, Calendar cal)
- getTime(String columnLabel, Calendar cal)
- getUnicodeStream
- getBinaryStream
AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14).
Data as JSON: /api/errors/ca2ff6770bea477c.
Report an issue: GitHub.