跳到主要内容

JEP 386：Alpine Linux 移植

概括​

将 JDK 移植到 Alpine Linux 以及其他在 x64 和 AArch64 架构上使用 musl 作为主要 C 库的 Linux 发行版，

动机​

Musl是基于 Linux 的系统的 ISO C 和 POSIX 标准中描述的标准库功能的实现。包括Alpine Linux和OpenWrt在内的多个 Linux 发行版都基于 musl，而其他一些发行版则提供可选的 musl 软件包（例如Arch Linux）。

Alpine Linux 发行版因其镜像较小而被广泛应用于云部署、微服务和容器环境中。例如， Alpine Linux 的Docker基础镜像小于 6 MB。使 Java 在此类设置中开箱即用，将允许 Tomcat、Jetty、Spring 和其他流行框架在此类环境中本机工作。

通过使用jlink (JEP 282)减小 Java 运行时的大小，用户将能够创建一个更小的映像来运行特定的应用程序。可以通过命令确定应用程序所需的模块集jdeps。例如，如果目标应用程序仅依赖于该java.base模块，则包含 Alpine Linux 的 Docker 映像和仅包含该模块的 Java 运行时以及服务器 VM 大小为 38 MB。

同样的动机也适用于嵌入式部署，它也有尺寸限制。

描述​

该 JEP 打算将Portola 项目整合到上游。

此端口不支持 HotSpot Serviceability Agent 的附加机制。

要在 Alpine Linux 上构建 JDK 的 musl 变体，需要以下软件包：

alpine-sdk alsa-lib alsa-lib-dev autoconf bash cups-dev cups-libs fontconfig fontconfig-dev freetype freetype-dev grep libx11 libx11-dev libxext libxext-dev libxrandr libxrandr-dev libxrender libxrender-dev libxt libxt-dev libxtst libxtst -dev linux-headers zip

安装这些包后，JDK 构建过程将照常进行。

如果有需求，其他架构的 Musl 端口可能会在后续增强中实现。

备择方案​

  • 将 musl 港口保留在 Portola 项目的下游。

  • 使用系统提供的 glibc 可移植层，或者使用操作系统映像构建并捆绑 glibc。这种替代方案的缺点是增加了映像占用空间并添加了不属于基本操作系统映像的依赖项。对于云部署场景，假设基本 Alpine Linux 3.11 musl 映像为 5.6 MB，附加 glibc 层为 26 MB，带有java.base模块和服务器 VM 的 Java 运行时为 38 MB，则具有 glibc 可移植性的静态占用空间开销图像中的图层为 30%。

测试​

  • 由于该端口影响共享代码，因此我们将在集成之前在基于 glibc 的 Linux 发行版（x64、AArch64 和 ARM32）、Windows 和 Mac 上运行 JCK 和 JTreg 测试，以确保不出现回归。

  • 我们将通过在 Alpine Linux 上运行 JTreg 测试的相关子集来验证 musl 端口的质量。我们将确保 Portola 到当前生产 JDK 版本的向下移植通过了 Alpine Linux 上的 JCK。我们将在 OpenWrt 上运行健全性测试。

  • 我们将在测试组中定义适合 musl 的新 JTreg 测试子集vm.musl。