我正在浏览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预发布版本进入了官方的OpenJDK8 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之上，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的生产就绪、经过认证的构建。
远离阿尔卑斯山脉的图像对阿尔卑斯-爪哇生态系统产生了巨大影响；自那以后，许多项目都将他们的图像从阿尔卑斯山移走了，这很不幸。您可以在此处找到更多详细信息。