apache/shardingsphere · error · UnsupportedOperationException

This SPI implementation does not support the use of this met

Error message

This SPI implementation does not support the use of this method.

What it means

InlineExpressionParser is an SPI with two optional Groovy-oriented default methods. handlePlaceHolder() has a default implementation that throws UnsupportedOperationException; it is only meaningful for parsers (like the built-in Groovy one) that understand ShardingSphere's ${...} placeholder expressions. The inline sharding algorithms (HintInlineShardingAlgorithm, ComplexInlineShardingAlgorithm, InlineShardingAlgorithm) call it to rewrite placeholder expressions, so configuring a parser SPI that does not override it makes those algorithms fail.

Source

Thrown at infra/expr/core/src/main/java/org/apache/shardingsphere/infra/expr/spi/InlineExpressionParser.java:57

     */
    List<String> splitAndEvaluate();
    
    /**
     * This method is used to return the inlineExpression String itself. In some cases, you may want to do
     * additional processing on inlineExpression to return a specific value, in which case you need to override this method.
     * Normally there is no need to use this method downstream, because this method only encapsulates the use of Groovy syntax
     * by ShardingSphere's existing algorithm classes.
     * An {@link org.apache.shardingsphere.infra.expr.spi.InlineExpressionParser} implementation that implements this method
     * will provide the following algorithm classes with the ability to convert original expressions.
     * 1. `org.apache.shardingsphere.sharding.algorithm.sharding.hint.HintInlineShardingAlgorithm`
     * 2. `org.apache.shardingsphere.sharding.algorithm.sharding.inline.ComplexInlineShardingAlgorithm`
     * 3. `org.apache.shardingsphere.sharding.algorithm.sharding.inline.InlineShardingAlgorithm`
     *
     * @return result processed inline expression defined by the SPI implementation
     * @throws UnsupportedOperationException Thrown to indicate that the requested operation is not supported.
     */
    default String handlePlaceHolder() {
        throw new UnsupportedOperationException("This SPI implementation does not support the use of this method.");
    }
    
    /**
     * Evaluate with arguments.
     * Normally there is no need to use this method downstream, because this method only encapsulates the use of Groovy syntax
     * by ShardingSphere's existing algorithm classes.
     * An {@link org.apache.shardingsphere.infra.expr.spi.InlineExpressionParser} implementation that implements this method
     * will provide the following algorithm classes with the ability to use expressions outside the Groovy language.
     * 1. `org.apache.shardingsphere.sharding.algorithm.sharding.hint.HintInlineShardingAlgorithm`
     * 2. `org.apache.shardingsphere.sharding.algorithm.sharding.inline.ComplexInlineShardingAlgorithm`
     * 3. `org.apache.shardingsphere.sharding.algorithm.sharding.inline.InlineShardingAlgorithm`
     *
     * @param map map
     * @return closure
     * @throws UnsupportedOperationException By default, users do not need to consider passing in additional parameters.
     */
    default String evaluateWithArgs(final Map<String, Comparable<?>> map) {
        throw new UnsupportedOperationException("This SPI implementation does not support the use of this method.");

View on GitHub (pinned to e952770a21)

Solutions

Use the default Groovy InlineExpressionParser when inline sharding algorithms are configured (keep the groovy module on the classpath).
Remove ${...} placeholder syntax from algorithm expressions if the alternative parser supports static expressions only.
If you own the parser SPI, override handlePlaceHolder() to implement placeholder handling for your expression syntax.

Example fix

# before (props)
props: expression-parser-type: LITERAL  # non-Groovy SPI without handlePlaceHolder
rules: sharding: algorithm: inline: expression: ds_${user_id % 2}

# after
props: expression-parser-type: GROOVY
rules: sharding: algorithm: inline: expression: ds_${user_id % 2}

Defensive patterns

Strategy: validation

Validate before calling

boolean placeholdersInRule = ruleExpression.contains("${");
if (placeholdersInRule && !"GROOVY".equalsIgnoreCase(props.get("expression-parser-type"))) { throw new ConfigurationException("inline algorithms need the Groovy parser"); }

Try / catch

try { parser.handlePlaceHolder(); } catch (UnsupportedOperationException e) { /* requires Groovy-based InlineExpressionParser */ }

Prevention

Keep the Groovy expression parser whenever inline sharding algorithms are configured.
Document SPI capability expectations when swapping expression parser implementations.

When it happens

Trigger: Setting a non-Groovy InlineExpressionParser SPI (via the expression parser SPI type in props) while a sharding rule uses InlineShardingAlgorithm / ComplexInlineShardingAlgorithm / HintInlineShardingAlgorithm with expressions containing ${...} placeholders like 'ds_${user_id % 2}'.

Common situations: Switching expression SPI type to avoid Groovy dependency or startup overhead and forgetting that inline sharding algorithms depend on Groovy placeholder semantics; custom inline-expression parser implementations contributed for other statement types that never implemented handlePlaceHolder; version upgrades where the SPI gained new default methods.

Related errors

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