★ FEATURED ARTICLE 简介JDK 17.0.8 是面向 macOS aarch64 架构Apple M1 芯片的 Java 开发工具包适合需要在 Mac 上编译、运行与调试 Java 项目的开发者。该版本属于 LTS 长期支持版内置密封类、Records、模式匹配 instanceof、增强 switch 表达式等新特性并对 M1 芯片做了针对性优化同时修复了多个安全漏洞并优化加密算法兼顾性能、安全与稳定性。压缩包共 362 个文件大小 168.12MB主要包含 71 个 jmod 模块文件用于模块化运行时、42 个 dylib 动态库、7 个 policy 安全策略以及 javac/java 命令行工具、JFR 诊断工具等目录按 bin、conf、lib、include、jmods 清晰划分include 下还提供 C/C 头文件便于 JNI 开发可快速找到编译打包、运行调试及模块管理所需组件。解压后即可获得完整 JDK/JRE 运行环境附带版权与许可信息适合从个人学习到企业级应用构建、长期维护项目等多种场景。目前已有 237 人学习下载可作为 macOS 上从入门到进阶的可靠 Java 17 开发基础。1. jdk-17.0.8 的 macos-aarch64 包Apple Silicon 上装 Java 的第一步如果你手里正好这个jdk-17_macos-aarch64_bin.tar.gz大概率是给一台 M 系列芯片的 Mac 装 Java 17——双击它不会弹安装器终端里也不会自动多出 java 命令它只是一份解压即用的压缩包。我见过不少人在这一步翻车文件下载完就以为装好了结果项目一跑直接报JAVA_HOME is not set或者java -version弹出一个陌生的老版本。这篇笔记就把这个包从下载到验证完整讲一遍为什么选 17.0.8、怎么解压迁移、JAVA_HOME 怎么配、多个 JDK 怎么切换以及我踩过的几个坑。内容同样适合刚拿到 M 系列 Mac、被某个框架强制要求 Java 17 的同学。2. 为什么是 17.0.8 而不是 21 或 11LTS、aarch64 和 tar.gz 的取舍2.1 aarch64 在 macOS 上的叫法与兼容层你拿到的文件名里写着aarch64但 macOS 系统本身更常叫它arm64。两者在 Apple Silicon 上指的是同一套指令集只是叫法来源不同Linux 生态习惯叫 aarch64Apple 生态习惯叫 arm64。如果你用uname -m查看M 系列芯片返回的是arm64而同样的命令在 Linux 的 ARM 服务器上返回aarch64。这个差异本身无伤大雅但会影响你写自动化脚本时的判断逻辑——我第 5 章会展开讲这个坑。为什么不能拿 x86_64 的 JDK 直接跑M 系列芯片虽然能通过系统自带的 Rosetta 兼容层运行 Intel 版程序但代价是启动更慢、内存占用更高而且个别 JDK 实现里依赖 JNI 的原生库会在 Intel 版上出现奇怪的崩溃。既然标题这个包就是 aarch64 的说明发行方已经为 Apple Silicon 做了原生产物直接用原生版本别绕路。2.2 LTS、版本节奏与 17.0.8 的定位Java 17 是 LTS长期支持版本这个身份意味着它有稳定的维护周期、安全补丁和生态兼容承诺。对比一下Java 11 是上一代 LTS属于“老而稳”Java 21 是最新 LTS特性多但生态迁移成本也高Java 17 恰好卡在两者之间——主流框架、构建工具、云原生运行时都把它作为默认基线。很多同学项目里java.version17/java.version写了好几年升级的意愿不大这时候 17 就是最保险的选择。那 17.0.8 呢这个版本号里的.0.8是安全更新序列号。17.0.8 属于 2023 年 7 月的 CPUCritical Patch Update修复了当时公开的若干高危漏洞。放到今天看它比 17.0.0 更稳比最新的 17.0.x 略老——但如果你是在某个受控环境里做交付团队锁定的版本恰好是 17.0.8那跟着这个文件走准没错。版本更迭带来的功能差异在 17 这个小版本区间内几乎感知不到真正的差异都在安全补丁里。2.3 tar.gz 为什么是手动安装最合适的形态JDK 在 macOS 上常见三种形态pkg 安装器、dmg 拖拽包、tar.gz 压缩包。pkg 会往系统目录写入文件并注册到 java_home 工具里省心但不够透明dmg 反正最后也是拖进目录tar.gz 则是三者里唯一“纯手工”的——解压到哪、用不用、什么时候清掉全由你控制也最容易在一台机器上同时存在多个 JDK。常见的 macOS 包管理器也能装 JDK但它默认的安装位置和手动放的目录不一样反而容易造成路径分裂。我的习惯是如果要精确控制版本就手动解开这个 tar.gz如果只是想“有个 Java 能用”那直接走包管理器更快。3. tar.gz 手动安装全过程解压、迁移、JAVA_HOME 与路径验证3.1 下载校验与解压文件完整性先确认拿到jdk-17_macos-aarch64_bin.tar.gz之后我先不急着解压。tar.gz 这类大文件在传输过程中偶尔会损坏解压到一半报gzip: invalid compressed data是很常见的事。官方下载页通常会给一个 SHA-256 校验值下载完先算一遍shasum -a 256 ~/Downloads/jdk-17_macos-aarch64_bin.tar.gz把输出和下载页给出的校验值逐字符对比。对得上就继续对不上就重新下载。别嫌这一步麻烦——我曾经跳过校验直接解压装完编译项目的时候抛了一堆莫名其妙的反编译错误排查半天最后发现是包本身坏了白费一个下午。校验没问题就解压。tar.gz 解出来通常是jdk-17.0.8.jdk这个目录形态.jdk后缀是 macOS 上 JDK bundle 的约定格式JavaVirtualMachines 目录里放的就是这种结构tar -xzf ~/Downloads/jdk-17_macos-aarch64_bin.tar.gz -C ~/Downloads/解压后看一眼目录结构确认有Contents/Home/bin/java和Contents/Info.plist。bin/java是实际操作文件Info.plist 里记录着版本元数据macOS 的/usr/libexec/java_home工具靠它识别这个 JDK 的存在。3.2 迁移到 /Library/Java/JavaVirtualMachines标准安装位置解压完的目录不能丢在下载文件夹里否则系统工具和 IDE 都找不到它。macOS 对 JDK 的标准搜寻路径是/Library/Java/JavaVirtualMachines你需要把它移过去。这个目录默认存在不需要自己创建sudo mv ~/Downloads/jdk-17.0.8.jdk /Library/Java/JavaVirtualMachines/为什么要 sudo/Library目录属于系统级普通用户没有写入权限。执行后会要求输入开机密码属于正常现象。移动完顺手做两件事确认目录权限所有者是 root并且可被系统读取ls -l /Library/Java/JavaVirtualMachines/如果这里显示jdk-17.0.8.jdk存在、且权限不是drwxr-xr-x或类似用 chmod 修正一下。某些情况下从下载目录直接 mv 过去文件权限会保持成当前用户这会导致其他账户访问时报权限错误IDE 里启动服务也会莫名失败。3.3 JAVA_HOME 配置与 source 生效终端识别新 JDK目录就位之后java命令还是不能在终端里直接用因为 shell 的 PATH 里没加这个 bin。配置 JAVA_HOME 是这一步的核心。macOS 自带一个定位工具/usr/libexec/java_home它能扫描 JavaVirtualMachines 目录并返回对应版本的绝对路径。在~/.zshrc里加上这两行export JAVA_HOME$(/usr/libexec/java_home -v 17) export PATH$JAVA_HOME/bin:$PATH第一行的-v 17表示要版本 17 的 JDK如果你机器上装了 17 和 21这个写法会精确返回 17 的路径而不是让系统随便挑一个。第二行把 JDK 的 bin 目录放到 PATH 最前面这样终端里输入java、javac会优先命中它。配置完要让当前终端重新加载配置文件然后验证source ~/.zshrc java -version javac -version正常会输出java version 17.0.8和javac 17.0.8。如果 javac 输出版本号和 java 不一致说明 PATH 里还有别的 JDK 在作怪优先检查 PATH 顺序别急着卸载另一个版本。注意-v 17匹配的是“主版本为 17”的任意 JDK。如果机器上同时存在 17.0.8 和 17.0.11它会选最新的那个。要精确锁 17.0.8请写成/usr/libexec/java_home -v 17.0.8。4. 多 JDK 共存的切换java_home、符号链接和 zsh 配置4.1 用 /usr/libexec/java_home 列出并定位所有 JDK日常开发里一台 Mac 上装好几个 JDK 很常见系统内置的旧版本、某个项目要求的 11、给新框架准备的 21。我不想在每次切换时去手改 zshrc所以第一步是先掌握“当前机器到底有哪些 JDK 可用”。macOS 的/usr/libexec/java_home -V大写 V能列出一份完整的清单/usr/libexec/java_home -V输出里会显示每个 JDK 的版本、架构和路径。如果你发现刚才装好的 17.0.8 没出现在列表里多半是目录没放对或者 Info.plist 有问题。如果出现了但默认版本不是你想要的用下面这个命令临时覆盖当前 shell 的默认 JDKexport JAVA_HOME$(/usr/libexec/java_home -v 17.0.8)这个临时变量只对当前终端窗口生效关掉就还原适合在一个窗口里快速测试项目对特定版本的兼容性。4.2 用 alias 做版本快捷切换一条命令切 JDK临时变量不够方便的时候改写成 zsh 函数按项目切换。在~/.zshrc里定义两个别名——一个切到 17一个切回系统默认alias jdk17export JAVA_HOME$(/usr/libexec/java_home -v 17.0.8); export PATH$JAVA_HOME/bin:$PATH; java -version alias jdkdefaultunset JAVA_HOME; export PATH/usr/bin:/bin:/usr/sbin:/sbin; java -version第一个别名做了三件事更新 JAVA_HOME、把新 bin 插到 PATH 前、确认生效。第二个别名比较粗暴直接回到系统默认的 java通常是 macOS 内置的旧版本。这种做法的好处是切换零成本坏处是 alias 只在交互式 shell 里有效——如果你在脚本里切 JDK得重新 source 或写成函数。4.3 目录命名与卸载时的边界条件多版本共存的前提是每个 JDK 目录名不冲突。/Library/Java/JavaVirtualMachines/下可以同时存在jdk-17.0.8.jdk和jdk-21.jdk名字不同互不影响。但要注意如果目录名里的版本号和内部 Info.plist 记录的版本不一致/usr/libexec/java_home会按 Info.plist 来识别但容易把自己搞糊涂。目录名尽量保持jdk-版本.jdk的规范别自己改成怪名字。卸载一个 JDK 很简单直接把对应目录删掉sudo rm -rf /Library/Java/JavaVirtualMachines/jdk-17.0.8.jdk删完再跑/usr/libexec/java_home -V确认列表里已经没有它。这里有个小坑如果当前 shell 的 JAVA_HOME 正好指向这个被删的目录再执行java会报No such file or directory不是报“java not found”。遇到这个现象别慌重新 source 一下 zshrc 或开个新终端就正常了。5. 安装后常见的 5 个坑aarch64 混淆、版本回退和权限问题排查5.1 装了新 JDK但 java -version 还是旧版本现象java -version输出的版本和你刚装的 17.0.8 完全无关比如显示的是11.0.x或者1.8.0_xxx但/usr/libexec/java_home -v 17.0.8能正确返回路径。原因PATH 里有一个优先级更高的旧 JDK 目录它排在$JAVA_HOME/bin前面。这种情况最常见的是之前手动改过 PATH或者某个工具比如 IDE 自带的 JRE被写进了系统 PATH。解决先查 PATH 里都有哪些 java。用which -a java列出所有候选路径然后确认当前命中是哪一个。修正方式是调整 zshrc 里 export PATH 的顺序确保$JAVA_HOME/bin在最前或者直接 unset 掉旧路径。没有其他办法能补救的话在当前终端里执行hash -r清掉命令缓存再验证一遍。5.2 uname -m 返回 arm64 而后台脚本在找 aarch64现象一个部署脚本里写着if [ $(uname -m) aarch64 ]; then ...在 M 系列 Mac 上永远走不进这个分支于是下载了 x86_64 版本的 JDK 或者其他依赖。原因macOS 上uname -m返回arm64而 Linux 的 ARM 架构返回aarch64。很多跨平台脚本写得太草率只认 Linux 的返回值。解决判断 Apple Silicon 的正确方式是同时兼容两种叫法脚本里写arch -arm64或者直接检查uname -m是否含有arm前缀。如果你在看第三方构建脚本遇到这种判断逻辑直接改掉别迁就它——否则你的 CI 在 macOS 上永远走错分支。5.3 IntelliJ IDEA 识别不到刚装的 17.0.8现象项目设置里 Project SDK 下拉列表没有17.0.8这个选项只有旧版本或者根本没有 SDK。原因IDE 扫描 JDK 时依赖/usr/libexec/java_home和 JavaVirtualMachines 目录。如果你把 JDK 放在了非标准路径比如自己建的/opt/jdk/IDE 自然找不到。解决打开 IDE 的 Project Structure选择 SDKs 页面手动添加 JDK 路径直接指向/Library/Java/JavaVirtualMachines/jdk-17.0.8.jdk/Contents/Home。添加完成后 IDE 会自动识读版本号。如果你确实是把 JDK 放在自定义路径下也别太担心——手动添加一次之后 IDE 会记住不会每次都要配。5.4 解压后 java 可执行文件没有执行权限现象tar.gz 解压完、移动到位之后执行/Library/Java/JavaVirtualMachines/jdk-17.0.8.jdk/Contents/Home/bin/java直接报Permission denied。原因tar.gz 打包时文件权限位没有完整保留或者解压前的下载目录有挂载属性影响了解压后的权限继承。我遇到过从一个内部镜像站下载的包解压后 bin 目录下的文件全都没有 x 位。解决直接给整个 Home 目录下的 bin 统一加权chmod x /Library/Java/JavaVirtualMachines/jdk-17.0.8.jdk/Contents/Home/bin/*加完再跑一遍java -version确认。这个操作不会影响其他文件放开权限的可执行文件都是 JDK 自带的命令行工具。5.5 下载页显示的大小和解压后的大小对不上现象下载页标着 180 MB 左右解压出来显示的也是 180 M但放进 JavaVirtualMachines 后查看磁盘空间发现占用了 400 MB 以上。原因.jdk目录里包含多个架构的共享库和调试符号文件部分文件是硬链接或稀疏文件ls显示的大小和实际磁盘占用不一定一致。这是正常现象。解决不用管它。如果你对磁盘占用敏感只需要确认/Library/Java/JavaVirtualMachines/下存在的目录数量即可。误删的话按第 4 章的方式重新装一份并不难别因为这个去优化一个 400 MB 的目录。6. 验证这版 JDK 真正可用的一个技巧从命令行到 IDE 的编译链路安装完成后最后一步是验证 JDK 不只是能跑java -version而是真的能用于实际编译链接。很多人只验证了 java 命令却没验证 javac 和类库链接结果一编译项目就各种缺模块。我习惯用一个包含 Java 17 新特性的小文件做端到端验证写一个用了record和switchpattern 匹配的类编译再运行cat /tmp/Jdk17Check.java EOF public class Jdk17Check { record Point(int x, int y) {} static String describe(Object obj) { if (obj instanceof Point(int x, int y)) { return point: x , y; } return other; } public static void main(String[] args) { System.out.println(describe(new Point(3, 4))); System.out.println(System.getProperty(java.version)); } } EOF cd /tmp javac Jdk17Check.java java Jdk17Check Java 17 的 record 和 instanceof pattern 是版本分水岭特性。如果 javac 报 syntax error说明编译器不是真正的 17如果能正常输出 point: 3, 4 和 17.0.8说明从编译到链接到 JVM 启动整条链路都是通的。 再往前走一步是 IDE 验证。Java 文件在 IntelliJ IDEA 或 VS Code 里打开后直接看底部状态栏的 Java 版本显示。IDEA 里打开 Build Output 日志确认编译用的编译器版本和 javac 一致。我之前在一台同事的机器上看过这种“java -version 显示 17IDE 里编译却用的 11”的割裂状态——原因就是 IDE 没手动指定 Project SDK给它自动选了个旧 JDK。所以别嫌 IDE 配置麻烦编译前先看两个地方Project SDK 和 Build Tools 里的 JDK 配置。 最后一步是清理测试文件因为 /tmp 目录重启后自动消失不清理也不会留垃圾。整个安装过程截止到这里JDK 17.0.8 在 Apple Silicon 上的安装、切换和验证体系就完整了。这套手动流程我用了很久它最大的价值不是“不用包管理器”而是让我对每一台机器的 Java 环境拥有完全的掌控力——环境出问题时我能准确说出问题出在哪一层而不是靠玄学重装一遍。希望帮到你。 p a hrefhttps://download.csdn.net/download/weixin_43800734/88423265 stylecolor:#ec7500;font-size:14px; 本文还有配套的精品资源点击获取 /a img altmenu-r.4af5f7ec.gif srchttps://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif stylewidth:16px;margin-left:4px;vertical-align:text-bottom;cursor:text; /p
阅读完成 · 觉得有帮助？
