nixpkgs Java 打包指南Ant 构建流程、CLASSPATH 约定与最小 JRE 定制【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs本文基于 nixpkgs 官方手册的 Java 语言章节doc/languages-frameworks/java.section.md系统讲解在 nixpkgs 中打包 Java 项目的完整套路以 Ant 为例的从源码构建模板、share/java目录约定及其背后的CLASSPATH自动装配机制、makeWrapper可执行入口生成以及 Java 9 模块系统时代如何用jre_minimal裁剪出只含所需模块的最小 JRE并辅以仓库中 openjdk 默认版本映射 与 JRE 实现源码 作为佐证。1. 用 Ant 从源码构建 Java 包对于基于 Ant 的 Java 项目nixpkgs 推荐的标准写法是用stdenv.mkDerivation描述完整的构建流程。文档给出的模板如下nativeBuildInputs中放入构建工具链buildPhase调用antinstallPhase把产物 JAR 安装到$out/share/javastdenv.mkDerivation { pname ...; version ...; src fetchurl { # ... }; nativeBuildInputs [ ant jdk stripJavaArchivesHook # removes timestamp metadata from jar files ]; buildPhase runHook preBuild ant # build the project using ant runHook postBuild ; installPhase runHook preInstall # copy generated jar file(s) to an appropriate location in $out install -Dm644 build/foo.jar $out/share/java/foo.jar runHook postInstall ; }几个要点值得展开各阶段的runHook pre*/post*调用不可省略。Nix 的构建框架stdenv通过 setup hooks 在preBuild、postBuild、preInstall、postInstall等时机注入通用行为日志记录、SOURCE_DATE_EPOCH处理等。即使你的包“看起来”只需要执行ant和install也必须保留这些 hook 调用否则各类全局钩子包括下面的stripJavaArchivesHook将不会生效。stripJavaArchivesHook与可复现构建JAR 本质上是 ZIP 归档压缩条目里会携带文件时间戳如果不加该 hook两次构建的.jar即使字节级内容相同其 zip 元数据也可能不同从而导致 Nix 哈希不稳定、构建不可复现。文档明确指出不使用该 hook “很可能会让生成的.jar文件变成非确定性的这不是最优的”同时也要注意使用了该 hook并不保证完全可复现例如归档条目顺序、源文件 mtime 等其他因素仍可能破坏字节级确定性。src的来源模板使用fetchurl示意实践中通常换成带sha256/hash校验的fetchurl { }、fetchFromGitHub { }等 fetcher保证输入的可重复获取。2.jdk别名与版本矩阵文档说明jdk是 OpenJDK 的别名——优先使用 nixpkgs 自编译的 OpenJDK不可用时则回退到 Zulu 预编译版本。在 all-packages.nix 中可以看到当前仓库维护的版本别名全貌openjdk8/openjdk11/openjdk17/openjdk21/openjdk25及各自的_headless变体并配有jdk8、jdk11、jdk17、jdk21等旧式别名各版本还导出对应的jre如jre8 openjdk8.jre默认 JDK 的定义在 all-packages.nix 第 3763-3765 行# default JDK jdk jdk21; jdk_headless jdk21_headless;即当前仓库里jdk指向jdk21。此外还有openjdkN-bootstrap系列自举编译用以及openjdk直接别名到默认jdk。如果你的包只依赖某一个具体版本例如 Java 8 生态的老项目应显式写jdk8而不是笼统的jdk避免默认版本升级带来的行为漂移。3.share/java约定与 CLASSPATH 自动装配JAR 文件按“用途”分两类安装这是 nixpkgs 里 Java 打包最重要的约定供其他包作为依赖使用的公共库 JAR安装到$out/share/java。包内部使用的私有 JAR安装到$out/share/package-name之类的私有位置避免污染依赖方的 classpath。公共库机制的原理是JDK 自带一个 stdenv setup hook它会把所有 build input 的share/java目录下的 JAR 追加进CLASSPATH环境变量。文档给的例子是若包libfoo把foo.jar装到自己的share/java目录而另一个包声明了{ buildInputs [ libfoo ]; nativeBuildInputs [ jdk ]; }那么构建时CLASSPATH会被自动设置为/nix/store/...-libfoo/share/java/foo.jar无需手写javac -cp ...。在仓库源码中可以印证这条链路openjdk/generic.nix 中 OpenJDK 派生项声明了propagatedBuildInputs [ setJavaClassPath ];意味着任何把 JDK/JRE 放进buildInputs/nativeBuildInputs的包都会传递性地获得该 classpath 钩子generic.nix 第 575-581 行 还针对 Java 11 之前的版本显式把setJavaClassPath写入 JRE 输出的propagated-build-inputs注释写明目的就是“让任何依赖 JRE 的包都能正确设置$CLASSPATH”Java 11 的 JRE 是 JDK 输出的一部分不再需要单独传播同文件 第 567-574 行 的preFixup会在$out/nix-support/setup-hook中自动设置JAVA_HOME这也是第 5 节--set JAVA_HOME技巧的来源。这条机制的实用含义是你的包只要把“对外暴露的 API JAR”放进share/java下游包只需在buildInputs里列出你这个包名classpath 就自动就位——依赖关系通过 Nix 的闭包精确表达而不是通过系统级的全局 classpath。4. 用 makeWrapper 为程序生成可执行入口如果你的 Java 包对外提供的是命令行程序而不是库需要生成一个包装脚本用 JRE 来启动它。文档推荐makeWrapper{ nativeBuildInputs [ makeWrapper ]; installPhase runHook preInstall mkdir -p $out/bin makeWrapper ${jre}/bin/java $out/bin/foo \ --add-flags -cp $out/share/java/foo.jar org.foo.Main runHook postInstall ; }包装脚本的真实内容是“$out/bin/foojre/bin/java -cp 你的jar 主类的 wrapper”makeWrapper会生成带 shebang 的可执行脚本并设置PATH等环境makeWrapper实现见 pkgs/build-support/setup-hooks/make-wrapper.sh。-cp参数按你的入口 JAR 与主类修改如果程序还依赖buildInputs中的库class 搜索路径已由第 3 节的CLASSPATH机制自动补齐wrapper 里只需写明本包自身的入口 JAR。生成的脚本会自动被 Nix 的patchShebangs/包装机制处理java可执行文件通过${jre}/bin/java的绝对路径引用因此最终产物在目标系统上可以脱离构建环境运行。5. Java 9 之后的模块系统与jre_minimal自 Java 9 引入 JPMSJava Platform Module System以来Java 发行版通常不再提供通用的 JREJRE 需要按应用所需的模块现场生成。文档对此的解释与仓库实现完全对应通用系统的默认jre就是完整 JDK。因为无法预知通用系统上会运行哪些应用nixpkgs 干脆让jre回退到完整 JDK。这一点在 all-packages.nix 第 3767-3775 行 有明确注释与定义# Since the introduction of the Java Platform Module System in Java 9, Java # no longer ships a separate JRE package. # # If you are building a minimal system/image, you are encouraged to use # jre_minimal to build a bespoke JRE containing only the modules you need. # # For a general-purpose system, jre defaults to the full JDK: jre jdk; jre_headless jdk_headless;构建最小系统/镜像时应 overridejre_minimal的modules参数只保留应用真正用到的模块let my_jre pkgs.jre_minimal.override { modules [ # The modules used by something and other combined: java.base java.logging ]; }; something (pkgs.something.override { jre my_jre; }); other (pkgs.other.override { jre my_jre; }); in ...jre_minimal的实现是 pkgs/development/compilers/openjdk/jre.nix几个源码细节值得注意函数签名第 1-8 行接收jdk、jdkOnBuild以及默认值为[ java.base ]的modules参数核心构建步骤就是一行jlink第 24-30 行buildPhase runHook preBuild jlink --module-path ${jdk}/lib/openjdk/jmods --add-modules ${lib.concatStringsSep , modules} --output $out runHook postBuild ;即从完整 JDK 的jmods目录中只链接你列出的模块输出就是一个独立的bin/lib布局的 JRE 目录由于使用jlink的 JDK 必须来自构建平台参数jdkOnBuild在 all-packages.nix 第 3779-3797 行 中通过buildPackages.jdkN传入天然支持交叉构建passthru里带了两个自测用例jre_minimal-hello与jre_minimal-hello-logging第 34-40 行分别验证最简 JRE 与带java.logging模块的 JRE 能否正常运行 hello 程序——你可以在仓库中查看 tests 目录 了解具体断言。各主版本另有jre11_minimal、jre17_minimal、jre21_minimal、jre25_minimal快捷包all-packages.nix 第 3777-3804 行默认jre_minimal跟随默认 JDK 版本。选择 JRE 底层的 JDK 变体你还可以指定jre_minimal基于哪个 JDK 构建例如选 headless 版本以避免引入 GTK 链接{ my_jre pkgs.jre_minimal.override { jdk jdk11_headless; }; }对无图形环境的服务器或最小镜像*_headless变体通常能显著减少 C 库依赖。JAVA_HOME的通用设置所有 JDK 包都在passthru中导出home属性见 generic.nix 第 596-597 行home ${finalAttrs.finalPackage}/lib/openjdk;。如果你的应用要求环境里设置JAVA_HOME可以用makeWrapper的--set参数以通用方式注入例如--set JAVA_HOME ${jdk.home}6. 使用非 OpenJDK 编译器GCJ文档最后说明也可以不用 OpenJDK 的javac而用其他 Java 编译器例如 GNU 编译器集合中的gcj{ nativeBuildInputs [ gcj ant ]; }此时 Ant 会自动使用gijGNU Java Runtime而不是 OpenJRE 来运行编译流程。这是一条兼容性逃生通道当某个项目依赖 GNU 工具链特有的行为时可以考虑但对绝大多数项目直接使用jdk仍然是 nixpkgs 中的主流做法。小结把本文要点浓缩成一张打包清单场景做法Ant 项目从源码构建stdenv.mkDerivationnativeBuildInputs [ ant jdk stripJavaArchivesHook ]buildPhase 调antinstallPhase 装 JAR对外暴露的库 JAR安装到$out/share/java下游经buildInputs自动进入CLASSPATH包内部私有 JAR安装到$out/share/package-name提供可执行程序makeWrapper包装jre/bin/java -cp ... 主类最小系统/镜像jre_minimal.override { modules [ ... ]; jdk ..._headless; }需要JAVA_HOMEmakeWrapper --set JAVA_HOME ${jdk.home}需要 GNU 工具链nativeBuildInputs [ gcj ant ]以上所有机制均有仓库源码支撑版本别名与jre jdk的默认值见 pkgs/top-level/all-packages.nixJDK 的 classpath/JAVA_HOME 注入见 pkgs/development/compilers/openjdk/generic.nix最小 JRE 的jlink实现与自测用例见 pkgs/development/compilers/openjdk/jre.nix而本文所有约定的权威描述以官方手册章节 doc/languages-frameworks/java.section.md 为准。【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 nixpkgs Java 打包指南：Ant 构建流程、CLASSPATH 约定与最小 JRE 定制
nixpkgs Java 打包指南Ant 构建流程、CLASSPATH 约定与最小 JRE 定制【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs本文基于 nixpkgs 官方手册的 Java 语言章节doc/languages-frameworks/java.section.md系统讲解在 nixpkgs 中打包 Java 项目的完整套路以 Ant 为例的从源码构建模板、share/java目录约定及其背后的CLASSPATH自动装配机制、makeWrapper可执行入口生成以及 Java 9 模块系统时代如何用jre_minimal裁剪出只含所需模块的最小 JRE并辅以仓库中 openjdk 默认版本映射 与 JRE 实现源码 作为佐证。1. 用 Ant 从源码构建 Java 包对于基于 Ant 的 Java 项目nixpkgs 推荐的标准写法是用stdenv.mkDerivation描述完整的构建流程。文档给出的模板如下nativeBuildInputs中放入构建工具链buildPhase调用antinstallPhase把产物 JAR 安装到$out/share/javastdenv.mkDerivation { pname ...; version ...; src fetchurl { # ... }; nativeBuildInputs [ ant jdk stripJavaArchivesHook # removes timestamp metadata from jar files ]; buildPhase runHook preBuild ant # build the project using ant runHook postBuild ; installPhase runHook preInstall # copy generated jar file(s) to an appropriate location in $out install -Dm644 build/foo.jar $out/share/java/foo.jar runHook postInstall ; }几个要点值得展开各阶段的runHook pre*/post*调用不可省略。Nix 的构建框架stdenv通过 setup hooks 在preBuild、postBuild、preInstall、postInstall等时机注入通用行为日志记录、SOURCE_DATE_EPOCH处理等。即使你的包“看起来”只需要执行ant和install也必须保留这些 hook 调用否则各类全局钩子包括下面的stripJavaArchivesHook将不会生效。stripJavaArchivesHook与可复现构建JAR 本质上是 ZIP 归档压缩条目里会携带文件时间戳如果不加该 hook两次构建的.jar即使字节级内容相同其 zip 元数据也可能不同从而导致 Nix 哈希不稳定、构建不可复现。文档明确指出不使用该 hook “很可能会让生成的.jar文件变成非确定性的这不是最优的”同时也要注意使用了该 hook并不保证完全可复现例如归档条目顺序、源文件 mtime 等其他因素仍可能破坏字节级确定性。src的来源模板使用fetchurl示意实践中通常换成带sha256/hash校验的fetchurl { }、fetchFromGitHub { }等 fetcher保证输入的可重复获取。2.jdk别名与版本矩阵文档说明jdk是 OpenJDK 的别名——优先使用 nixpkgs 自编译的 OpenJDK不可用时则回退到 Zulu 预编译版本。在 all-packages.nix 中可以看到当前仓库维护的版本别名全貌openjdk8/openjdk11/openjdk17/openjdk21/openjdk25及各自的_headless变体并配有jdk8、jdk11、jdk17、jdk21等旧式别名各版本还导出对应的jre如jre8 openjdk8.jre默认 JDK 的定义在 all-packages.nix 第 3763-3765 行# default JDK jdk jdk21; jdk_headless jdk21_headless;即当前仓库里jdk指向jdk21。此外还有openjdkN-bootstrap系列自举编译用以及openjdk直接别名到默认jdk。如果你的包只依赖某一个具体版本例如 Java 8 生态的老项目应显式写jdk8而不是笼统的jdk避免默认版本升级带来的行为漂移。3.share/java约定与 CLASSPATH 自动装配JAR 文件按“用途”分两类安装这是 nixpkgs 里 Java 打包最重要的约定供其他包作为依赖使用的公共库 JAR安装到$out/share/java。包内部使用的私有 JAR安装到$out/share/package-name之类的私有位置避免污染依赖方的 classpath。公共库机制的原理是JDK 自带一个 stdenv setup hook它会把所有 build input 的share/java目录下的 JAR 追加进CLASSPATH环境变量。文档给的例子是若包libfoo把foo.jar装到自己的share/java目录而另一个包声明了{ buildInputs [ libfoo ]; nativeBuildInputs [ jdk ]; }那么构建时CLASSPATH会被自动设置为/nix/store/...-libfoo/share/java/foo.jar无需手写javac -cp ...。在仓库源码中可以印证这条链路openjdk/generic.nix 中 OpenJDK 派生项声明了propagatedBuildInputs [ setJavaClassPath ];意味着任何把 JDK/JRE 放进buildInputs/nativeBuildInputs的包都会传递性地获得该 classpath 钩子generic.nix 第 575-581 行 还针对 Java 11 之前的版本显式把setJavaClassPath写入 JRE 输出的propagated-build-inputs注释写明目的就是“让任何依赖 JRE 的包都能正确设置$CLASSPATH”Java 11 的 JRE 是 JDK 输出的一部分不再需要单独传播同文件 第 567-574 行 的preFixup会在$out/nix-support/setup-hook中自动设置JAVA_HOME这也是第 5 节--set JAVA_HOME技巧的来源。这条机制的实用含义是你的包只要把“对外暴露的 API JAR”放进share/java下游包只需在buildInputs里列出你这个包名classpath 就自动就位——依赖关系通过 Nix 的闭包精确表达而不是通过系统级的全局 classpath。4. 用 makeWrapper 为程序生成可执行入口如果你的 Java 包对外提供的是命令行程序而不是库需要生成一个包装脚本用 JRE 来启动它。文档推荐makeWrapper{ nativeBuildInputs [ makeWrapper ]; installPhase runHook preInstall mkdir -p $out/bin makeWrapper ${jre}/bin/java $out/bin/foo \ --add-flags -cp $out/share/java/foo.jar org.foo.Main runHook postInstall ; }包装脚本的真实内容是“$out/bin/foojre/bin/java -cp 你的jar 主类的 wrapper”makeWrapper会生成带 shebang 的可执行脚本并设置PATH等环境makeWrapper实现见 pkgs/build-support/setup-hooks/make-wrapper.sh。-cp参数按你的入口 JAR 与主类修改如果程序还依赖buildInputs中的库class 搜索路径已由第 3 节的CLASSPATH机制自动补齐wrapper 里只需写明本包自身的入口 JAR。生成的脚本会自动被 Nix 的patchShebangs/包装机制处理java可执行文件通过${jre}/bin/java的绝对路径引用因此最终产物在目标系统上可以脱离构建环境运行。5. Java 9 之后的模块系统与jre_minimal自 Java 9 引入 JPMSJava Platform Module System以来Java 发行版通常不再提供通用的 JREJRE 需要按应用所需的模块现场生成。文档对此的解释与仓库实现完全对应通用系统的默认jre就是完整 JDK。因为无法预知通用系统上会运行哪些应用nixpkgs 干脆让jre回退到完整 JDK。这一点在 all-packages.nix 第 3767-3775 行 有明确注释与定义# Since the introduction of the Java Platform Module System in Java 9, Java # no longer ships a separate JRE package. # # If you are building a minimal system/image, you are encouraged to use # jre_minimal to build a bespoke JRE containing only the modules you need. # # For a general-purpose system, jre defaults to the full JDK: jre jdk; jre_headless jdk_headless;构建最小系统/镜像时应 overridejre_minimal的modules参数只保留应用真正用到的模块let my_jre pkgs.jre_minimal.override { modules [ # The modules used by something and other combined: java.base java.logging ]; }; something (pkgs.something.override { jre my_jre; }); other (pkgs.other.override { jre my_jre; }); in ...jre_minimal的实现是 pkgs/development/compilers/openjdk/jre.nix几个源码细节值得注意函数签名第 1-8 行接收jdk、jdkOnBuild以及默认值为[ java.base ]的modules参数核心构建步骤就是一行jlink第 24-30 行buildPhase runHook preBuild jlink --module-path ${jdk}/lib/openjdk/jmods --add-modules ${lib.concatStringsSep , modules} --output $out runHook postBuild ;即从完整 JDK 的jmods目录中只链接你列出的模块输出就是一个独立的bin/lib布局的 JRE 目录由于使用jlink的 JDK 必须来自构建平台参数jdkOnBuild在 all-packages.nix 第 3779-3797 行 中通过buildPackages.jdkN传入天然支持交叉构建passthru里带了两个自测用例jre_minimal-hello与jre_minimal-hello-logging第 34-40 行分别验证最简 JRE 与带java.logging模块的 JRE 能否正常运行 hello 程序——你可以在仓库中查看 tests 目录 了解具体断言。各主版本另有jre11_minimal、jre17_minimal、jre21_minimal、jre25_minimal快捷包all-packages.nix 第 3777-3804 行默认jre_minimal跟随默认 JDK 版本。选择 JRE 底层的 JDK 变体你还可以指定jre_minimal基于哪个 JDK 构建例如选 headless 版本以避免引入 GTK 链接{ my_jre pkgs.jre_minimal.override { jdk jdk11_headless; }; }对无图形环境的服务器或最小镜像*_headless变体通常能显著减少 C 库依赖。JAVA_HOME的通用设置所有 JDK 包都在passthru中导出home属性见 generic.nix 第 596-597 行home ${finalAttrs.finalPackage}/lib/openjdk;。如果你的应用要求环境里设置JAVA_HOME可以用makeWrapper的--set参数以通用方式注入例如--set JAVA_HOME ${jdk.home}6. 使用非 OpenJDK 编译器GCJ文档最后说明也可以不用 OpenJDK 的javac而用其他 Java 编译器例如 GNU 编译器集合中的gcj{ nativeBuildInputs [ gcj ant ]; }此时 Ant 会自动使用gijGNU Java Runtime而不是 OpenJRE 来运行编译流程。这是一条兼容性逃生通道当某个项目依赖 GNU 工具链特有的行为时可以考虑但对绝大多数项目直接使用jdk仍然是 nixpkgs 中的主流做法。小结把本文要点浓缩成一张打包清单场景做法Ant 项目从源码构建stdenv.mkDerivationnativeBuildInputs [ ant jdk stripJavaArchivesHook ]buildPhase 调antinstallPhase 装 JAR对外暴露的库 JAR安装到$out/share/java下游经buildInputs自动进入CLASSPATH包内部私有 JAR安装到$out/share/package-name提供可执行程序makeWrapper包装jre/bin/java -cp ... 主类最小系统/镜像jre_minimal.override { modules [ ... ]; jdk ..._headless; }需要JAVA_HOMEmakeWrapper --set JAVA_HOME ${jdk.home}需要 GNU 工具链nativeBuildInputs [ gcj ant ]以上所有机制均有仓库源码支撑版本别名与jre jdk的默认值见 pkgs/top-level/all-packages.nixJDK 的 classpath/JAVA_HOME 注入见 pkgs/development/compilers/openjdk/generic.nix最小 JRE 的jlink实现与自测用例见 pkgs/development/compilers/openjdk/jre.nix而本文所有约定的权威描述以官方手册章节 doc/languages-frameworks/java.section.md 为准。【免费下载链接】nixpkgsNix Packages collection NixOS项目地址: https://gitcode.com/GitHub_Trending/ni/nixpkgs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考