JEP 386: Alpine Linux Port | Alpine Linux 端口
摘要
将 JDK 移植到 Alpine Linux 上，以及使用 musl 作为其主要 C 库的其他 Linux 发行版上，支持 x64 和 AArch64 架构，
动机
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 和仅包含该模块及服务器 VM 的 Java 运行时的 Docker 镜像可以压缩到 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 上进行基本测试。
我们将在
vm.musl测试组中定义一个新的 JTreg 测试子集，该子集适用于 musl。