apache/shardingsphere · error · SQLFeatureNotSupportedException
getParameterClassName
Error message
getParameterClassName
What it means
SQLFeatureNotSupportedException thrown by AbstractUnsupportedOperationParameterMetaData.getParameterClassName(int). The class name of the Java object a driver would bind to a '?' depends on backend type mapping, which ShardingSphere does not perform at prepare time (it routes SQL after local parsing), so this final method always throws.
Source
Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedOperationParameterMetaData.java:63
@Override
public final int getScale(final int parameter) throws SQLException {
throw new SQLFeatureNotSupportedException("getScale");
}
@Override
public final int getParameterType(final int parameter) throws SQLException {
throw new SQLFeatureNotSupportedException("getParameterType");
}
@Override
public final String getParameterTypeName(final int parameter) throws SQLException {
throw new SQLFeatureNotSupportedException("getParameterTypeName");
}
@Override
public final String getParameterClassName(final int parameter) throws SQLException {
throw new SQLFeatureNotSupportedException("getParameterClassName");
}
@Override
public final int getParameterMode(final int parameter) throws SQLException {
throw new SQLFeatureNotSupportedException("getParameterMode");
}
}
View on GitHub (pinned to e952770a21)
Solutions
- Drive binding from your own type map (parameter index -> Java class) instead of ParameterMetaData.
- Catch SQLFeatureNotSupportedException and fall back to setObject(i, value) which lets ShardingSphere pass the value through to the backend driver.
- Keep a non-sharded DataSource for the metadata-dependent module if the probe cannot be removed.
Example fix
// before Class<?> clazz = Class.forName(pmd.getParameterClassName(1)); // after Class<?> clazz = expectedParamTypes.get(1); // from your own mapping
Defensive patterns
Strategy: try-catch
Validate before calling
Class<?> expected = paramTypeMap.get(index); if (expected == null) { ps.setObject(index, value); } // never ask ParameterMetaData for the class Try / catch
try { className = pmd.getParameterClassName(1); } catch (final SQLFeatureNotSupportedException e) { className = value.getClass().getName(); } Prevention
- Use setObject(i, value) which ShardingSphere passes through to the backend
- Keep reflective binders away from ParameterMetaData
- Map parameter classes in configuration, not at runtime
When it happens
Trigger: ps.getParameterMetaData().getParameterClassName(i) on a ShardingSphere PreparedStatement; invoked by reflective binders that instantiate parameter objects by class name.
Common situations: Legacy EJB/JDO-style frameworks, generic table-editing GUIs, or copy paths ported from drivers that implement getParameterClassName; surfaces right after the datasource URL is switched to jdbc:shardingsphere:.
Related errors
AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14).
Data as JSON: /api/errors/869e9976a29ba18f.
Report an issue: GitHub.