如何绕开Integer、String等final修饰基础类型无法继承的限制？适配JPA Criteria API

Java 中String、Integer这类 final 修饰的类从语法层面就禁止继承，没有合法的绕开方式，你期望的「通过继承基础类型实现统一父类兼容字面量和查询参数」的思路无法实现，可采用以下两种成熟方案解决你在 JPA Criteria API 开发中遇到的混合传参问题：

方案1：统一参数接口+静态适配（推荐） #

定义统一的参数接口，分别实现字面量包装类和查询参数包装类，再通过重载的静态方法做自动适配，可保留编译期类型检查，运行无额外风险。

示例代码如下：

1. 定义统一接口

public interface StringRepresentation {
    // 内置统一转换为Criteria表达式的方法，适配后续查询构造
    Expression<String> toExpression(CriteriaBuilder cb);
}

2. 分别实现字面量和查询参数的包装类

// 字符串字面量包装实现
public class StringLiteral implements StringRepresentation {
    private final String value;

    public StringLiteral(String value) {
        this.value = value;
    }

    @Override
    public Expression<String> toExpression(CriteriaBuilder cb) {
        return cb.literal(value);
    }
}

// 查询参数包装实现
public class QueryStringParam implements StringRepresentation {
    private final QueryParameter<String> param;

    public QueryStringParam(QueryParameter<String> param) {
        this.param = param;
    }

    @Override
    public Expression<String> toExpression(CriteriaBuilder cb) {
        return param;
    }
}

3. 编写适配方法和业务方法

// 重载的静态适配方法，自动根据入参类型包装为统一接口实例
public static StringRepresentation $(String literal) {
    return new StringLiteral(literal);
}

public static StringRepresentation $(QueryParameter<String> param) {
    return new QueryStringParam(param);
}

// 业务方法直接接收统一接口的可变参数
public void withFeatures(StringRepresentation... features) {
    CriteriaBuilder cb = entityManager.getCriteriaBuilder();
    List<Expression<String>> exprList = new ArrayList<>();
    for (StringRepresentation feat : features) {
        exprList.add(feat.toExpression(cb));
    }
    // 后续将exprList传入in方法构造查询条件即可
}

调用方式非常简洁，仅需对参数加一层$()包装，完全支持混合传参：

myCar.withFeatures($("Seat Heating"), $("Metallic Color"), $("Trailer Hitch"));
myCar.withFeatures($(new QueryParam<String>("MyFavourit")));
myCar.withFeatures($("Seat Heating"), $(new QueryParam<String>("LoveThatColor")), $("Trailer Hitch"));

方案2：Object入参+运行期类型判断 #

如果不想添加任何调用侧的包装代码，可以直接用Object作为可变参数的类型，内部判断类型做转换，缺点是丢失编译期类型检查，传错参数类型需到运行期才会报错。

示例代码如下：

public void withFeatures(Object... features) {
    CriteriaBuilder cb = entityManager.getCriteriaBuilder();
    List<Expression<String>> exprList = new ArrayList<>();
    for (Object feat : features) {
        if (feat instanceof String s) {
            exprList.add(cb.literal(s));
        } else if (feat instanceof QueryParameter<?> qp && qp.getParameterType() == String.class) {
            exprList.add((Expression<String>) qp);
        } else {
            throw new IllegalArgumentException("不支持的参数类型：" + feat.getClass().getName());
        }
    }
    // 后续构造查询条件逻辑和方案1一致
}

调用侧完全不需要修改，和你期望的写法完全一致：

myCar.withFeatures("Seat Heating", "Metallic Color", "Trailer Hitch");
myCar.withFeatures(new QueryParam<String>("MyFavourit"));
myCar.withFeatures("Seat Heating", new QueryParam<String>("LoveThatColor"), "Trailer Hitch");

不建议尝试用反射、字节码修改等hack手段破解final类的继承限制，这类方案在JDK9+的模块化体系下会直接失效，还会引发各类兼容性、可维护性问题，上述两种常规方案已经可以完全覆盖你的需求。

内容的提问来源于stack exchange，提问作者JBStonehenge