apache/shardingsphere · error · SQLFeatureNotSupportedException

setTypeMap

Error message

setTypeMap

What it means

ShardingSphere's JDBC driver does not implement the java.sql.Connection method setTypeMap (installing a custom SQL-to-Java type map on the connection). The abstract base class AbstractUnsupportedOperationConnection, which ShardingSphereConnection extends, overrides it as final and unconditionally throws SQLFeatureNotSupportedException. ShardingSphere does not maintain per-connection custom type mappings, so the mutator is permanently unsupported. The exception is thrown the moment the method is invoked on any connection produced by the ShardingSphere Driver.

Source

Thrown at jdbc/src/main/java/org/apache/shardingsphere/driver/jdbc/unsupported/AbstractUnsupportedOperationConnection.java:74

    
    @Override
    public final String nativeSQL(final String sql) throws SQLException {
        throw new SQLFeatureNotSupportedException("nativeSQL");
    }
    
    @Override
    public final void abort(final Executor executor) throws SQLException {
        throw new SQLFeatureNotSupportedException("abort");
    }
    
    @Override
    public final Map<String, Class<?>> getTypeMap() throws SQLException {
        throw new SQLFeatureNotSupportedException("getTypeMap");
    }
    
    @Override
    public final void setTypeMap(final Map<String, Class<?>> map) throws SQLException {
        throw new SQLFeatureNotSupportedException("setTypeMap");
    }
    
    @Override
    public int getNetworkTimeout() throws SQLException {
        throw new SQLFeatureNotSupportedException("getNetworkTimeout");
    }
    
    @Override
    public void setNetworkTimeout(final Executor executor, final int milliseconds) throws SQLException {
        throw new SQLFeatureNotSupportedException("setNetworkTimeout");
    }
    
    @Override
    public Array createArrayOf(final String typeName, final Object[] elements) throws SQLException {
        throw new SQLFeatureNotSupportedException("createArrayOf");
    }
    
    @Override

View on GitHub (pinned to e952770a21)

Solutions

  1. Delete the setTypeMap call and rely on standard JDBC types or application-side conversion.
  2. Route the type-map-dependent logic through a separate native DataSource.
  3. Unwrap the real backend connection and set the type map on it directly if backend-local behavior is sufficient.
Defensive patterns

Strategy: try-catch

Validate before calling

boolean supportsOp = false;
try {
    connection.getMetaData(); // connection is alive
    // JDBC has no capability flag for individual methods; probe once per JVM:
    supportsOp = probeSupport(connection); // reflective/one-time guarded call
} catch (final SQLException ignored) {
}
// Simpler and recommended: capability-check by driver URL
boolean isShardingSphere = url.startsWith("jdbc:shardingsphere:");
if (isShardingSphere) {
    // skip the unsupported call, use the alternative API path
}

Try / catch

try {
    connection.setTypeMap(/* args */);
} catch (final SQLFeatureNotSupportedException e) {
    // expected on ShardingSphere connections: fall back to supported API
    log.debug("Driver does not support setTypeMap, using fallback", e);
}

Prevention

When it happens

Trigger: Calling Connection.setTypeMap(map) on a ShardingSphere connection.

Common situations: Legacy Oracle/JDBC code that maps SQL object types (STRUCT) to Java classes; ORM bootstrap code that installs type maps after obtaining a connection.

Related errors

AI-assisted analysis of apache/shardingsphere@e952770a21 (2026-08-14). Data as JSON: /api/errors/08bccb247e62a000. Report an issue: GitHub.