[Feature] 草案：提升 HMCL 的 JAR 版本到 23

[burningtnt]

概述 | Summary

将用于编译 HMCL 的 JDK 版本，和运行时最低 JRE 版本提升至 Java 23。

• 开发者：建议使用 JDK 25 开发；
• 一般用户：推送 JRE 25 + JavaFX 25 的安装包；
• Windows x86 (32-bit) 用户：推送 JRE 23 的安装包。

原因 | Reason

JEP 454: Foreign Function & Memory API 于 Java 22 进入稳定状态。该 JEP 提供了在不使用 JNI 的前提下，访问本机原生 API 和手动控制堆外内存的能力。
对于 HMCL 而言，我们可以抛弃 JNA 和其中的平台相关动态链接库文件，减小最终 JAR 包体积；将短暂需要大量内存的操作迁移到手动控制的堆外内存，降低 -Xmx 默认值以节约内存。

JEP 479: Remove the Windows 32-bit x86 Port 移除了 Windows x86 架构的支持。自 Java 24 起，OpenJDK 项目不再支持上述系统。因此，停留在 JRE 23 可以继续保留旧系统的兼容性。

另外，现在 JavaFX 会兼容 Java N-2 ，所以 JavaFX 25 也兼容 Java 23，我们可以对所有 64 位平台统一下载 JavaFX 25；JDK 23 - 25 并没有提供非常多好用的 API，不升级到 Java 25 的代价是可以接受的。

风险 | Risks

1. FFM 因不在 Windows x86 上支持 stdcall 而无法调用任何 WinAPI；
2. 暂未找到可用于 Windows x86 的 JRE 23 产物发布页，我们可能还得自己从源码构建；

替代方案 | Alternatives

• 发布第二个 LTS 版本（但我们大概率是没这个精力的）作为最后兼容 Windows x86 的版本，然后迁移到 Java 25，或；
• 对着 Windows x86 用户竖中指，然后不发布 LTS 版本，直接迁移到 Java 25，或；
• 使用黑魔法在 Java 21 上使用预览状态的 FFM，且想办法适配 Java 21、22、23 的 FFM API 变动。

[hmr-BH]

我认为应当放弃对于x86的支持，并且保留迁移到Java23之前的HMCL版本供给x86用户使用。原因是，第一，Java23及后续LTS版本已不再提供官方x86构建，若由我们自行分发，会因跨境带宽限制、运营商QoS策略差异导致下载体验不可控，甚至完全不可用。第二，高版本JDK可能隐式依赖仅存在于64位Windows内核中的系统调用，在32位环境下会表现为无法复现的段错误或静默崩溃，放任这种错误是对用户不负责的行为。第三，x86架构的物理内存寻址上限为4GB（实际可用约3.2-3.5GB），而现代Minecraft实例堆内存需求往往超过此阈值，即使勉强启动也会因OOM崩溃。

现在我来回答shulker的一些问题，虽然他对我百般刁难，但是为了防止有人无法从以上内容中提取到有效信息，我还是说明一下：

1、停止x86更新，那如果微软做出一些破坏性更新，必须要更新启动器怎么办？首先，这些更新影响的通常是身份验证协议或新版游戏运行时，而32位系统受限于内存和CPU指令集，早已无法承载1.18+（甚至更早）版本的Minecraft。对于只能运行旧版游戏的旧硬件，启动器的功能性更新并非刚需；反之，若微软真的强制废弃旧协议，x86用户群体也无法通过升级硬件来解决，这是结构性淘汰而非软件适配问题。

2、解决下载的问题有多困难？我们需要认识到，国内网络环境具有显著的地域异质性——不仅有跨省际的骨干网拥塞，还存在某些地区对非备案IP的阻断策略（例如已知的内蒙古、新疆部分运营商对境外CDN的屏蔽）。自建CDN节点需要ICP备案、运营商合作及持续的带宽成本，对于开源项目而言是沉重的持续性支出。若依赖GitHub Release等境外源，则必然导致部分用户完全无法获取。与其提供不可靠的服务，不如明确边界，引导用户停留在功能完整的旧版本。

3、我们放弃x86支持不就相当于完全剥夺了用户使用HMCL的权利吗，还不如给用户留个机会？我们需要精准了解x86存量用户的群体：十年前、十五年前购置的设备早已普及64位处理器，至今仍在使用32位系统的用户大多是电脑小白，其技术能力往往不足以诊断"Java版本与架构不匹配"或"本地JNI库加载失败"等深层问题。继续推送基于Java23的HMCL版本，实质是将技术债务转嫁给最终用户，他们可能在升级后遭遇启动器崩溃等严重问题，却因缺乏日志分析能力而陷入求助无门的困境。与其提供"有机会但大概率失败"的虚假希望，不如给用户保留一个稳定可用的。

[qyl27]

我认为应该使用Java25，MC在26.1版本开始使用25（此前是21），在开发和运行中直接要求使用和游戏本体一致的Java版本更合适。
现在，最后一个32位版本的Windows早已停止支持，且OpenJDK在JEP 503中已经移除了所有x86 port，因此Minecraft在即将发布的版本中使用Java25代表游戏将不再支持只有x86的旧平台。此外，很多软件也事实上无法在这样的旧设备中运行。
HMCL是开源软件，维护旧设备的兼容性也不利于项目本身的健康发展。

[Glavo]

第一，Java23及后续LTS版本已不再提供官方x86构建，若由我们自行分发，会因跨境带宽限制、运营商QoS策略差异导致下载体验不可控，甚至完全不可用。

我们对此并不需要提供自动下载功能，所以可以使用网盘进行分发。

第二，高版本JDK可能隐式依赖仅存在于64位Windows内核中的系统调用（如VirtualAlloc2的特定标志位或WSL相关API），在32位环境下会表现为无法复现的段错误或静默崩溃，放任这种错误是对用户不负责的行为。

JDK 23 依然提供对 32 位 x86 平台的官方支持，正常情况下不应当出现这种问题。

第三，x86架构的物理内存寻址上限为4GB（实际可用约3.2-3.5GB），而现代Minecraft实例堆内存需求往往超过此阈值，即使勉强启动也会因OOM崩溃。

Intel 32 位 x86 CPU 实际是 36 位地址线，整个平台可以使用的内存上限是 64GiB，32 位只是单进程的寻址上限。4GiB 对于单进程通常是足够的。

另外我们也没有计划为 32 位平台提供对 1.20.5/24w14a 及更高版本的支持。

[hmr-BH]

第一，Java23及后续LTS版本已不再提供官方x86构建，若由我们自行分发，会因跨境带宽限制、运营商QoS策略差异导致下载体验不可控，甚至完全不可用。

我们对此并不需要提供自动下载功能，所以可以使用网盘进行分发。

第二，高版本JDK可能隐式依赖仅存在于64位Windows内核中的系统调用（如VirtualAlloc2的特定标志位或WSL相关API），在32位环境下会表现为无法复现的段错误或静默崩溃，放任这种错误是对用户不负责的行为。

JDK 23 依然提供对 32 位 x86 平台的官方支持，正常情况下不应当出现这种问题。

第三，x86架构的物理内存寻址上限为4GB（实际可用约3.2-3.5GB），而现代Minecraft实例堆内存需求往往超过此阈值，即使勉强启动也会因OOM崩溃。

Intel 32 位 x86 CPU 实际是 36 位地址线，整个平台可以使用的内存上限是 64GiB，32 位只是单进程的寻址上限。4GiB 对于单进程通常是足够的。

另外我们也没有计划为 32 位平台提供对 1.20.5/24w14a 及更高版本的支持。

网盘分发非常麻烦，Java23压缩后体积大于100MB，放蓝奏云要VIP，放百度网盘……就是有没有一种可能，包括百度网盘在内的众多网盘运营商早就在多年前放弃了32位。就算用户用的是旧版本，没有VIP下载速度非常慢，还不如直接用官方启动器。如果继续推送更新，想象一下，用户某天打开HMCL发现Java过时需要下载新的，好不容易开始下载了，下载需要俩小时。

[Glavo]

短期内我也没有放弃对 x86 32 位平台支持的计划。

首先，并非所有 32 位平台都已经被 JDK 官方放弃。在 HMCL 所支持的平台中，还有 ARM32 平台依然受到 JDK 官方支持。

放弃对 x86 32 位平台的支持意味着我们将很难测试对 32 位平台的适配，相关代码可能很快就开始出现问题。

其次，使用 x86 32 位 JDK 也是测试与当前系统架构不匹配的 JDK 的首选方式。Windows ARM64、macOS ARM64 以及 Linux LoongArch64 平台中都经常会出现这种情况，放弃对 x86 32 位 JDK 的支持后，我们将很难在开发环境测试这种情况。

[hmr-BH]

短期内我也没有放弃对 x86 32 位平台支持的计划。

首先，并非所有 32 位平台都已经被 JDK 官方放弃。在 HMCL 所支持的平台中，还有 ARM32 平台依然受到 JDK 官方支持。

放弃对 x86 32 位平台的支持意味着我们将很难测试对 32 位平台的适配，相关代码可能很快就开始出现问题。

其次，使用 x86 32 位 JDK 也是测试与当前系统架构不匹配的 JDK 的首选方式。Windows ARM64、macOS ARM64 以及 Linux LoongArch64 平台中都经常会出现这种情况，放弃对 x86 32 位 JDK 的支持后，我们将很难在开发环境测试这种情况。

您说的非常对，但是考虑到您工作繁忙，因此x86兼容性问题就算发生也不会在短时间内修复。

或许应尽早

将更多精力放在启动器新功能和其他优化上。况且更新到Java23会引入新的未知变量，这对于x86平台的兼容工作反而是一种阻力。

[Calboot]

或许应尽早

将更多精力放在启动器新功能和其他优化上。况且更新到Java23会引入新的未知变量，这对于x86平台的兼容工作反而是一种阻力。

所以你到底是不支持升级到 JDK23 还是不支持暂时保留 32 位兼容？

以及我个人认为，保留 32 位的兼容不会比兼容龙芯等小众架构更加困难。

如果继续推送更新，想象一下，用户某天打开HMCL发现Java过时需要下载新的，好不容易开始下载了，下载需要俩小时。

关于这种情况，只需要在更新前进行提示就好了啊（虽然这可能需要小改一下）。以及，hmcl 不会静默更新，为什么会突然发现 Java 过时呢？

[hmr-BH]

或许应尽早

将更多精力放在启动器新功能和其他优化上。况且更新到Java23会引入新的未知变量，这对于x86平台的兼容工作反而是一种阻力。

所以你到底是不支持升级到 JDK23 还是不支持暂时保留 32 位兼容？

以及我个人认为，保留 32 位的兼容不会比兼容龙芯等小众架构更加困难。

并非，32位是上游已经明确放弃支持的架构，龙芯至少有专门的团队在维护。况且这两个的性质也不同，一个相当于是“拖累”，一个相当于是“前进”

如果继续推送更新，想象一下，用户某天打开HMCL发现Java过时需要下载新的，好不容易开始下载了，下载需要俩小时。

关于这种情况，只需要在更新前进行提示就好了啊（虽然这可能需要小改一下）。以及，hmcl 不会静默更新，为什么会突然发现 Java 过时呢？

我的方案在前面提到了，升级到Java23后立即终止32位支持，为32位用户提供旧版本。HMCL虽然不会静默更新，但是用户一般不看更新日志，所以没办法及时发现。等他们再次打开HMCL的时候就遭罪了