编译Java桌面应用应选用哪个JDK版本才能兼容最多桌面用户？

问题根因 #

你遇到的是Java生态最常见的版本兼容坑之一：

1. 本地使用OpenJDK 17编译生成的class文件主版本号为61，而朋友安装的JRE 8最高只能识别版本号为52的class文件，必然会抛出版本不支持的错误
2. Oracle面向普通用户的java.com下载页默认提供的始终是Java 8，这是为了兼容二十年前的遗留Java客户端应用，普通用户几乎不可能自行找到正确的高版本JRE下载渠道

行业最佳实践 #

按推荐优先级从高到低排列：

• 优先采用运行时随应用打包的分发方式，不依赖用户自行安装Java环境
  这是当前Java桌面/命令行应用发布的主流方案，从根源上杜绝版本错配问题：
  • 用jlink工具根据应用依赖的JDK模块，裁剪生成精简版专属JRE，和JAR包一起打包分发，用户解压后直接运行启动脚本即可，不需要提前安装任何Java环境，裁剪后的运行时通常仅几十MB大小
  • 用jpackage工具直接将应用、精简JRE打包为对应操作系统的原生安装包（Windows下为msi/exe，macOS下为dmg/pkg，Linux下为deb/rpm），安装后和本地原生应用体验完全一致，双击即可启动，用户完全感知不到Java的存在
  • 如果对启动速度、包体积有更高要求，可以用GraalVM将应用直接编译为平台原生机器码，不需要附带任何运行时，不过如果应用用到反射、动态代理等动态特性，需要提前做元数据配置，适配成本稍高
• 如果确实需要让用户自行安装JRE，编译时严格对齐目标版本
  走“用户自备Java环境”的分发路径时，编译时必须加--release <目标最低版本>参数，比如要兼容JRE 8就用--release 8，这个参数会同时完成三件事：生成对应低版本号的class文件、校验调用的所有API在目标版本中是否存在、生成适配目标版本的字节码，避免出现编译通过但低版本运行报错的问题。
  注意不要使用老旧的-source/-target参数，这两个参数不会校验API兼容性，很容易出现用了高版本新增的方法、编译没报错但低版本运行时抛NoSuchMethodError的隐性问题。如果用Maven、Gradle等构建工具，直接把这个参数配置到构建规则中即可，不需要每次手动传入。
• 加前置版本校验，给出明确提示
  在应用的启动脚本最开头加入版本检测逻辑，先执行java -version获取当前环境的Java版本，如果版本低于要求的最低阈值，直接输出清晰的错误提示，明确告知用户需要安装的最低Java版本，不要等JVM抛出用户看不懂的技术类报错。
• 发布页明确标注运行要求
  在下载页用醒目的文字标注应用要求的最低Java版本，不要默认用户知道版本差异，避免用户误装低版本JRE浪费时间。

注意：Java的向下兼容指的是高版本JVM可以运行低版本编译的class文件，反过来完全不成立，不存在“低版本JRE跑高版本编译的程序”的兼容逻辑，这是很多Java开发者刚接触时容易搞错的点。

内容的提问来源于stack exchange，提问作者Daniel R. Collins