[Bug] 无法安装 GTNH: java.lang.StringIndexOutOfBoundsException: Range [0, 2) out of bounds for length 0

[copi143]

问题描述 | Bug Description

尝试安装 GT_New_Horizons_2.9.0-beta-1_Java_17-25.zip 会失败，而 GT_New_Horizons_2.9.0-beta-1_Java_8.zip 能够成功安装。

启动器崩溃报告 / 启动器日志文件 | Launcher Crash Report / Launcher Log File

2026-06-11T03-53-24.log

[burningtnt]

看起来和本地的文件下载缓存有关，不是整合包特定问题。可先尝试进入设置 - 通用清空下载缓存，然后再试一次

[copi143]

清空下载缓存后还是同一个报错

2026-06-11T21-07-01.log

[sakanadesu0449]

确认在Windows平台，HMCL 3.15.0.346可以复现完全相同的问题

[DrLa7ency]

今天更新GTNH的时候也遇到了一模一样的问题，翻了一下源码大致定位了问题，似乎是启动器bug
问题出现在HMCL下载lzma-0.0.1.jar这个库时，并且貌似只有这个库导致了问题

首先产生报错的地方是org.jackhuang.hmcl.util.CacheRepository的这一段，在安装lzma-0.0.1.jar这个库的时候fileExists传入的hash是空字符串，然而fileExists并没有检查长度问题（因为本来也不应该是空的），并且将其传入getFile，导致如下第三行的substring数组越界

// org.jackhuang.hmcl.util.CacheRepository
protected Path getFile(String algorithm, String hash) {
    hash = hash.toLowerCase(Locale.ROOT);
    return this.getCacheDirectory().resolve(algorithm).resolve(hash.substring(0, 2)).resolve(hash);
}

protected boolean fileExists(String algorithm, String hash) {
    if (hash == null) {
        return false;
    } else {
        Path file = this.getFile(algorithm, hash);
        if (Files.exists(file, new LinkOption[0])) {
            try {
                return DigestUtils.digestToString(algorithm, file).equalsIgnoreCase(hash);
            } catch (IOException var5) {
                return false;
            }
        } else {
            return false;
        }
    }
}

向上溯源可以找到空hash的来源是DefaultCacheRepository这里的第三行，经过调试发现info确实存在，但是sha1和size都是0（调试出的toString是LibraryDownloadInfo [url=https://libraries.minecraft.net/lzma/lzma/0.0.1/lzma-0.0.1.jar, sha1=, size=0]）

// org.jackhuang.hmcl.download.DefaultCacheRepository
public Optional<Path> getLibrary(Library library) {
    LibraryDownloadInfo info = library.getDownload();
    String hash = info.getSha1();
    if (this.fileExists("SHA-1", hash)) {
        return Optional.of(this.getFile("SHA-1", hash));
        } else {
            //...

个人临时为了跳过这个库的下载在本地简单加了一个逻辑，最终成功下载

// org.jackhuang.hmcl.download.DefaultCacheRepository
public Optional<Path> getLibrary(Library library) {
    LibraryDownloadInfo info = library.getDownload();
    String hash = info.getSha1();
    // 宇宙级dirty fix
    if (info.getUrl().equals("https://libraries.minecraft.net/lzma/lzma/0.0.1/lzma-0.0.1.jar"))
        return Optional.of(Path.of("E://Downloads//lzma-0.0.1.jar"));
    if (this.fileExists("SHA-1", hash)) {
        return Optional.of(this.getFile("SHA-1", hash));
    } else {

临时应急方案（如果你真的很想玩GTNH）
我顺便在附件里扔了一个简单的class覆盖临时补丁，原理是让HMCL跳过lzma的下载

temporary_fix.zip

使用方法
1.手动从上面的路径下载lzma，把lzma的jar包放到HMCL exe文件同目录
2.把HMCL的exe文件用7zip打开，用附件里的class文件覆盖掉对应路径的class文件
3.打开HMCL，下载整合包
4.把lzma的jar包放回对应的libraries文件夹
5.把HMCL换回原版
覆盖之前记得要复制一份HMCL的exe文件，而且为了防止未来不确定的问题下载完一定要切换回原来的版本

所以问题大致就是Library没有sha1并且没有对应的处理，不过具体原因还没有深挖
假如sha1的获取渠道那里就是空的，那么就可能需要决定这种文件在下载缓存中应该放在什么文件夹，并且还要决定怎么搞checksum
或者仿照Mojang在2014整的笑话，参见MCL-2191