java - 为什么 OpenJDK 发布的新 Java 8 映像不再基于 Alpine,而是基于 Debian 10(Buster)?
问题描述
我正在浏览 OpenJDK 发布的最新图像:https ://hub.docker.com/layers/openjdk/library/openjdk/8u252-jre-slim-buster/images/sha256-01dfdeac537b9d9adcb2399028fba063733a77186c5264e6b059987002c0e48c?context= explore
所有新的 Java 8 映像都使用基于 Debian,是否有任何官方声明 OpenJDK 从 Alpine 迁移到 Debian,为什么?
为什么 OpenJDK 发布的新 Java 8 映像不再基于 Alpine,而是基于 Debian 10(Buster)?
解决方案
2019 年 5 月,OpenJDK Dockerhub 映像已转向使用官方认证的 OpenJDK 二进制文件,而不是发行版 OpenJDK 包:
https ://github.com/docker-library/openjdk/pull/322
这些二进制文件是AdoptOpenJDK 提供的普通上游 OpenJDK 构建,由 RedHat 测试和支持。二进制文件是基于 glibc 的,因此虽然它们与 Debian 兼容,但它们与 Alpine Linux 不兼容。
背景:
直到 2019 年 5 月,OpenJDK 都有 Debian 和 Alpine 映像,使用打包的 OpenJDK 版本并通过分发包管理器安装,apt
适用于 Debian, apk
适用于 Alpine。Debian 和 Alpine 软件包由社区构建和维护,并且在商业企业 OpenJDK 构建的范围内没有经过验证 - 例如,它们通常没有经过JCK认证。
然后,发生了一起事件,其中 Debian 打包的 OpenJDK 8 预发布版本已进入官方 OpenJDK 8 docker 映像。该问题最初是在此线程中报告的:
https ://mail.openjdk.java.net/pipermail/jdk8u-dev/2019-May/009330.html
之后,决定 OpenJDK 镜像将只使用官方的、经过 JCK 测试的构建,以拥有一个“真实来源”。这个决定同时影响了 Debian 和 Alpine 镜像。
Alpine OpenJDK 支持:
OpenJDK 项目还没有对 Alpine Linux 的官方支持。Alpine Linux 基于musl libc构建,这是一个最小且严格的 POSIX 实现,通常与标准glibc不兼容。musl libc 的 OpenJDK 移植正在 OpenJDK 的项目Portola下开发。
Alpine Linuxopenjdk8
软件包由IcedTea提供。IceaTea 项目为 OpenJDK 6、7 和 8 提供构建,并在 OpenJDK 尚未完全开源时重新启动。这些构建是社区制作的,不是官方的 OpenJDK 构建。此外,Alpine Linux OpenJDK 8 IcedTea 版本是由 Alpine 维护人员从源代码构建的。因此,这些构建不能被视为生产就绪、经过认证的 OpenJDK 构建。
远离 Alpine 图像对 Alpine Java 生态系统产生了巨大影响;从那以后,许多项目都将他们的图像从 Alpine 移走了,这是不幸的。您可以在此处找到更多详细信息。
推荐阅读
- android - BLE(蓝牙低功耗)
- python-3.x - 如何在带有 utf-8 十六进制字符的字符串中转换带有 unicode 字符的字符串?
- asp.net-core - IIS 重新启动站点后,Asp.net Core 进程未关闭
- sql-server - SQL-SERVER-获取表之间的关系
- c++ - 使用标准库自定义构建 cmake 也适用于 gcc 版本较低的项目
- mysql - 将数据从 mysql 获取到 Apache Spark (scala) 时出错
- cryptography - 椭圆曲线中带负数的标量乘法
- r - 如何向 plotly 添加第三个值,以便在 ggplotly 上显示行/观察 ID 变量
- amazon-web-services - aws lambda 在 s3 上写入文件 - javascript
- java - Grafana 正则表达式