prestodb/presto · error · IllegalStateException

Unsupported java type %s

Error message

Unsupported java type %s

What it means

ClickHouseRecordCursor constructor assigns each column's read function by the function's Java return type (long, boolean, double, Slice, or block). If a registered read function's javaType is none of these it throws IllegalStateException "Unsupported java type %s". This is an internal invariant violation — a read function was registered with an unexpected Java representation.

Source

Thrown at presto-clickhouse/src/main/java/com/facebook/presto/plugin/clickhouse/ClickHouseRecordCursor.java:84

            ReadMapping readMapping = clickHouseClient.toPrestoType(columnHandles.get(i).getClickHouseTypeHandle())
                    .orElseThrow(() -> new VerifyException("Unsupported column type"));
            Class<?> javaType = readMapping.getType().getJavaType();
            ReadFunction readFunction = readMapping.getReadFunction();

            if (javaType == boolean.class) {
                booleanReadFunctions[i] = (BooleanReadFunction) readFunction;
            }
            else if (javaType == double.class) {
                doubleReadFunctions[i] = (DoubleReadFunction) readFunction;
            }
            else if (javaType == long.class) {
                longReadFunctions[i] = (LongReadFunction) readFunction;
            }
            else if (javaType == Slice.class) {
                sliceReadFunctions[i] = (SliceReadFunction) readFunction;
            }
            else {
                throw new IllegalStateException(format("Unsupported java type %s", javaType));
            }
        }

        try {
            connection = clickHouseClient.getConnection(ClickHouseIdentity.from(session), split);
            statement = clickHouseClient.buildSql(session, connection, split, columnHandles);
            log.debug("Executing: %s", statement.toString());
            resultSet = statement.executeQuery();
        }
        catch (SQLException | RuntimeException e) {
            throw handleSqlException(e);
        }
    }

    @Override
    public long getReadTimeNanos()
    {
        return 0;

View on GitHub (pinned to 55bb57d202)

Solutions

  1. Ensure the presto-clickhouse plugin version exactly matches the Presto server version
  2. Redeploy/restore a clean plugin build if the deployment was patched
  3. Avoid querying columns whose types were added by custom patches
  4. Report/upgrade: this indicates a connector bug for that type

Example fix

// before (deployment)
plugin dir contains presto-clickhouse-0.273.jar on a 0.284 server
// after
replace plugin jar with presto-clickhouse-0.284.jar matching the server
Defensive patterns

Strategy: try-catch

Validate before calling

// Verify plugin jar version matches server before deploying
String serverVersion = prestoServerVersion;
String pluginVersion = jarName("presto-clickhouse-*.jar");
if (!pluginVersion.endsWith(serverVersion + ".jar")) {
    throw new IllegalStateException("presto-clickhouse plugin " + pluginVersion + " mismatches server " + serverVersion);
}

Try / catch

try {
    runQuery(...);
} catch (IllegalStateException e) {
    if (e.getMessage().startsWith("Unsupported java type")) {
        // redeploy matching plugin build / exclude the offending column
    } else throw e;
}

Prevention

When it happens

Trigger: Querying ClickHouse columns whose type's read function returns a Java type outside {long, boolean, double, Slice, Block}; usually after a connector/plugin version mismatch where type registration and read functions disagree.

Common situations: Deploying a mismatched Presto server vs plugin build; custom/patched type support; newly added Presto types not handled by the ClickHouse reader.

Related errors


AI-assisted analysis of prestodb/presto@55bb57d202 (2026-09-04). Data as JSON: /api/errors/4f0c30c86e4c249f. Report an issue: GitHub.