Skip to content

Feature: 嵌入 ZipFS #4031

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 4 commits into from

Conversation

burningtnt
Copy link
Member

@burningtnt burningtnt commented Jun 22, 2025

目前 HMCL 依赖 jdk ZipFS。依照在崩溃分析群的观察,部分玩家在使用损坏的 ZipFS 实现时会出现无法解析整合包、模组信息等问题。将这一仅有 120K 的库嵌入 HMCL 中可以解决这一问题,并不再需要面对不同发行版中 zipfs 的不同表现。此外,这将给予我们自定义报错信息等方面更大自由度。

@Glavo
Copy link
Member

Glavo commented Jun 28, 2025

我觉得本 PR 意义不大,HMCL 并没有一定要使用 zipfs 的理由。

我计划在 3.7.14 中删除对 zipfs 的依赖,这项工作已经在本地进行了一半了。

@burningtnt
Copy link
Member Author

burningtnt commented Jun 29, 2025

我觉得本 PR 意义不大,HMCL 并没有一定要使用 zipfs 的理由。

我计划在 3.7.14 中删除对 zipfs 的依赖,这项工作已经在本地进行了一半了。

zipfs 相较于 common-compress 有更简单的 API,可以高度简化代码。将 zipfs 迁移到 common-compress 不是一个好主意

例如,如果想要计算相对路径,zipfs 可以这么写

Path p = root.resolve("sub-file");
Files.newBufferedReader(p, StandardCharsets.UTF_8)

而 common-compress 必须手动对 String 进行处理,没有 resolve 这类工具方法。我看不出忠于 common-compress 除了可以直接获取到文件名的 byte[] 序列外有任何优势

如果可能,我们可以照抄 common-vfs 的写法,在 common-compress 基础上建构 fs 层 API

…le cannot be implemented with ZipFS. So I did this to prove they are wrong.
@burningtnt burningtnt closed this Jul 3, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants