按示例pom引入依赖后使用graal.js报FileSystemProvider实例化错误

这个异常的触发根源不在GraalJS依赖本身，实际触发逻辑是：

1. GraalJS初始化执行上下文时，会调用JDK提供的FileSystemProvider.installedProviders()获取系统默认文件系统实例
2. JDK会通过ServiceLoader机制全量扫描类路径下所有实现FileSystemProvider接口的SPI服务
3. 扫描到项目引入的Apache MINA SSHD组件提供的org.apache.sshd.client.subsystem.sftp.SftpFileSystemProvider时，该类实例化失败
4. 这个实例化错误没有被JDK内部的SPI扫描逻辑拦截，直接沿着调用栈传递到GraalJS的初始化流程，最终被PolyglotException包装抛出

通常SftpFileSystemProvider实例化失败的原因有两个：一是sshd相关的传递依赖版本不匹配，类路径下缺少该类初始化所需的依赖类；二是SPI服务文件被打包到类路径中，但对应的实现类根本不存在于当前类加载路径。

方案1：从根源修复SPI加载错误 #

• 检查项目中所有org.apache.sshd相关依赖的版本，确保sshd-core、sshd-common、sshd-sftp等组件的版本完全对齐，避免因版本错配导致类加载失败
• 如果项目本身没有SFTP远程文件访问的需求，直接在构建工具依赖中排除org.apache.sshd相关的SFTP子模块，或者移除打包产物中META-INF/services/java.nio.file.spi.FileSystemProvider文件内对应SFTP Provider的注册行，从根源避免扫描加载这个无效实现
• 启动前可单独执行测试代码打印所有已加载的FileSystemProvider列表，定位具体是哪一个类缺失或版本不兼容，精准修复依赖问题

方案2：绕开全局SPI扫描逻辑 #

如果项目暂时无法调整现有依赖版本，可在初始化GraalJS引擎时手动指定文件系统实现，跳过JDK全局的SPI扫描环节：

// 手动构建GraalJS引擎，替换默认的文件系统实现
Engine graalEngine = Engine.newBuilder()
        .fileSystem(FileSystems.newDefaultFileSystem(null))
        .build();
ScriptEngine graaljsEngine = new GraalJSScriptEngine(
        Context.newBuilder("js")
                .engine(graalEngine)
                .build(),
        null
);

这种方式会直接使用GraalJS内置的文件系统实现，不会触发JDK全局的FileSystemProvider扫描流程，从调用链上避开报错点。注意需要根据业务实际需求，给自定义文件系统配置对应的文件访问权限，避免运行时的文件读写逻辑被沙箱拦截。

方案3：配置SPI加载规则跳过错误Provider #

JDK本身支持在SPI加载时指定需要忽略的实现类，可在JVM启动参数中添加：

-Dsun.nio.fs.FileSystemProvider.loading.ignore=org.apache.sshd.client.subsystem.sftp.SftpFileSystemProvider

直接告诉JDK在扫描FileSystemProvider时跳过这个实例化失败的类，避免该错误打断初始化流程。

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