Saxon9迁移至Saxon10 HE：Java扩展类是否需单独对应命名空间

这不是Saxon 10 HE的固有限制，是Saxon10出于安全考量调整了Java扩展函数的默认解析规则，完全可以通过修改Java端配置/代码，实现原有XSL文件零改动复用。

Saxon 9 和 Saxon 10 HE 在扩展函数解析逻辑上的核心差异：

• Saxon 9 默认支持同一个自定义命名空间下，自动跨多个候选Java类匹配扩展方法，因此可以用单个common_namespace前缀，调用原本集中在一个类里的所有函数
• Saxon 10 HE 默认启用严格绑定规则：一个自定义命名空间的Java扩展，必须绑定到唯一的Java类，否则会直接抛出“函数不存在”的错误，这是需要为每个类单独配置命名空间的根本原因

方案1：实现自定义扩展函数工厂 #

• 编写实现ExtensionFunctionFactory接口的类，绑定到原有XSL中使用的common_namespace命名空间URI
• 工厂内部维护所有拆分后Java类的列表，当收到该命名空间下的函数查找请求时，依次遍历所有候选类，匹配函数名和参数签名，找到对应方法后动态生成可调用的函数实现
• 将这个自定义工厂注册到Saxon的Configuration实例上，替代默认的Java扩展解析逻辑
  这种方式下XSL中所有common_namespace:function_name的调用会完全正常解析，不需要修改任何XSL内容。

方案2：保留统一门面类做转发 #

• 重建原本的集中式工具类作为空的门面类，在类中为所有拆分出去的方法写静态转发逻辑，方法内部直接调用对应拆分类的同名方法
• 保持原有命名空间的绑定目标不变（仍然指向这个门面类）
  Saxon解析扩展函数时会直接在门面类中匹配到对应方法，XSL不需要做任何修改。

方案3：使用内置配置放开跨类解析 #

• 如果之前使用的是Saxon原生的java:格式命名空间URI，可以将URI调整为指向所有拆分类的公共包路径
• 在Saxon配置中开启ALLOW_UNAMBIGUOUS_CLASS_NAME_FOR_EXTENSION_FUNCTION选项，允许同一命名空间下匹配公共包内多个类的方法
• 注意必须保证所有拆分类中的函数名不重名，否则会触发歧义解析报错

• 上述放开跨类解析的配置，仅适用于完全信任XSL代码来源的场景：如果需要执行不可信的第三方XSL代码，这类配置会带来安全风险，这也是Saxon10默认收紧规则的核心原因
• 自定义函数工厂时，需要为重名的跨类方法配置匹配优先级，避免出现函数解析错配的问题

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