必须检查eclipse.ini中-vm参数是否显式指向OpenJDK 17的javaw.exe，且-vm行须在-vmargs之前、路径含空格时需加英文引号、必须精确到bin\javaw.exe而非JDK根目录或jre路径，改后须重启Eclipse。
检查 eclipse.ini 中的 -vm 参数是否指向 OpenJDK 17 的 javaw.exe
很多“运行环境不兼容”报错，实际是 Eclipse 启动时根本没用上你装的 OpenJDK 17，而是 fallback 到了系统默认或旧版本 JVM。关键看 eclipse.ini 文件里有没有显式、正确地指定 -vm 路径。
常见错误包括：
-
-vm行写在了-vmargs后面（必须在-vmargs之前） - 路径中含中文或空格，且没用引号包裹（如
C:\Program Files\Java\jdk-17.0.2\bin\javaw.exe应写成"C:\Program Files\Java\jdk-17.0.2\bin\javaw.exe"） - 路径指向的是
jre\bin或bin\java.exe（Windows 下必须是javaw.exe，Linux/macOS 是java） - 路径写成了 JDK 根目录（如
C:\...\jdk-17.0.2），而没落到bin子目录
改完保存，**必须重启 Eclipse** —— 修改 eclipse.ini 不会热生效。
确认项目编译器级别和运行时 JRE 都设为 17
即使 Eclipse 自身启动用了 JDK 17，单个项目仍可能被配成 Java 8，导致运行时报 InaccessibleObjectException 或 UnsupportedClassVersionError。
两处必须同步检查：
- 项目右键 → Properties → Java Compiler → 勾选 Enable project specific settings，并把 Compiler compliance level 设为
17 - 同个 Properties 窗口 → Java Build Path → Libraries 标签页 → 展开
JRE System Library→ 点 Edit… → 选Execution environment→ 选JavaSE-17（不是 “Workspace default JRE”）
如果列表里没有 JavaSE-17，说明你还没在 Preferences → Java → Installed JREs 中添加 OpenJDK 17 的安装路径。
遇到 InaccessibleObjectException 就别硬扛，该降级就降级
这个异常本质不是配置问题，而是代码在 Java 17 上触了模块系统的红线 —— 比如反射访问 java.util.TimerTask.state，而 java.base 没 open java.util 给你。
如果你跑的是老项目（比如用 abbot、swingutils、某些旧测试框架），别指望加 --add-opens 参数一劳永逸。真实场景中容易踩的坑有：
- 加了
--add-opens java.base/java.util=ALL-UNNAMED，但漏了其他包（java.desktop、java.naming等常被反射调用） - 参数只加在
eclipse.ini里（影响 IDE 自身），没加到 Run Configuration → Arguments → VM arguments（影响项目运行） - 用了多个依赖，每个都要求不同 opens，最终参数过长、顺序混乱，JVM 拒绝启动
这时候最稳的解法：在项目层面单独指定 JDK 8 运行时，而不是强行让整个工作区迁移到 17。
别忽略系统架构位数匹配这个低级但致命的问题
Exit code=13 报错几乎 100% 是 32/64 位不匹配。Eclipse 是 64 位，但你配的 JDK 是 32 位（比如下载了 i586 版本），或者反过来。
验证方式很简单：
- 命令行执行
java -version，看输出末尾有没有64-Bit - 打开任务管理器 → 详细信息 → 找
eclipse.exe，看“平台”列是不是64 位 - 进 JDK 安装目录，看
bin下有没有server\jvm.dll（64 位）还是client\jvm.dll（32 位）
一旦不一致，删掉错位的 JDK，重装对应架构的 OpenJDK 17（Temurin 推荐用 temurin-17-jdk-aarch64 或 temurin-17-jdk-amd64）。这个点看似基础，但排查时最容易跳过。
