跳到主要内容

JEP 386: Alpine Linux 移植

QWen Max 中英对照 JEP 386: Alpine Linux Port

总结​

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

动机​

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

由于镜像体积小，Alpine Linux 发行版在云部署、微服务和容器环境中被广泛采用。例如，Docker 的 Alpine Linux 基础镜像 不到 6 MB。使 Java 能够在此类环境中开箱即用，将允许 Tomcat、Jetty、Spring 和其他流行的框架在这些环境中原生运行。

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

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

描述​

本 JEP 旨在将 Portola Project 上游集成。

此端口将不支持 HotSpot Serviceability Agent 的 attach 机制。

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

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 移植可能会在后续的增强中实现。

替代方案​

  • 在 Portola 项目中保持 musl 移植的下游版本。

  • 使用系统提供的 glibc 兼容层，或者将 glibc 构建并打包到操作系统镜像中。这种替代方案的缺点是会增加镜像的占用空间，并添加一个不属于基础操作系统镜像的依赖项。对于云部署场景，假设基础的 Alpine Linux 3.11 musl 镜像是 5.6 MB，额外的 glibc 层为 26 MB，而包含 java.base 模块和服务器虚拟机 (server 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 上进行健全性测试。

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