Temurin-build: 缺少DLL意味着用户被迫下载Microsoft Visual C ++可再发行组件

@johanvos-这是您期望我们的发行版拥有的东西，还是JavaFX软件包的一部分？

它是OpenJDK发行版的一部分，因此出于一致性的原因，我认为它也应该是AdoptOpenJDK发行版的一部分？

太好了谢谢！ @ ali- ince /

将dll包含在软件包中会增加OpenJDK发行版的大小，这是一个考虑因素。 Microsoft不建议静态链接或将DLL包含在您自己的目录中，因为OS /安全更新可能不适用于那些运行时

查看： https :

看起来这些是OS级别的库，但是它们以某种方式更改了名称。 来自MS社区的建议是，我们应该使用mincore.lib，它是所有api表面的填充程序，但是该二进制文件仅适用于Windows 8+。

另外，我们可以在我们的安装程序包中分发完整的Visual C ++可再发行组件安装程序。

什么是一个好的选择？

@sunnythepooh

另外，我们可以在我们的安装程序包中分发完整的Visual C ++可再发行组件安装程序。

uck！

AdoptOpenJDK应该是jdk.java.net版本的直接替代品。

如果您让最终用户无所适从，那将对零依赖jlink应用程序的价值主张造成极大的损害。

恕我直言，尽管我可以理解为什么您会考虑在AdoptOpenJDK中包括VC ++ redist的原因，但仅应在.dll需要它的情况下

对于JavaFX软件包，将其包含进来更有意义。

或将其包含在AdoptOpenJavaFX额外功能中：-)

对于JavaFX软件包，将其包含进来更有意义。

我可以看到，理想世界中的.dll应该放在JavaFX包中可能是完全正确的。

但是，与此同时，直到您可以开始提供自己的AdoptOpenJavaFX程序包或说服Gluon在其程序包中包含.dll为止，AdoptOpenJDK才可用于JavaFX应用程序。

我敢肯定，有各种各样更好的长期方法，但是与此同时，对于AdoptOpenJDK来说，这是一种不可接受的状态。

我认为这里的主要问题可能是AdoptOpenJDK使用与Visual Studio构建版本不同的Visual Studio版本（我会检查，但可能是VS2013）构建JDK（假定缺少DLL名称，可能是VS2017）。

我将首先尝试验证VS的版本并在此处进行更新。

我已经注意到AdoptOpenJDK 12（热点）现在具有必需的DLL，因此所有内容都非常适合JavaFX应用程序。

谢谢！！！

我已经注意到AdoptOpenJDK 12（热点）现在具有必需的DLL，因此所有内容都非常适合JavaFX应用程序。

谢谢！！！

很好听-对于Java 11和8，我怀疑此问题现在将在每夜解决。 @ ali-ince我们现在是否要针对所有版本使用VS 2017进行构建？

尚未@karianna ，它仍在进行中。 当我们切换到vs2017时，我将更新此线程。

快速更新；

1. JDK11u 64位版本现已切换到VS2017。
2. JDK11u 32位版本位于VS2013上。 将通过11.0.4更新发布一个使JDK11u 32位能够与VS2017进行编译的修复程序，与此同时，我们将切换到VS2017。
3. JDK8u的32位和64位版本现在已切换到VS2013（以前它们是在VS2010 / VS2013上混合使用的）。 我们也正在努力使它们也基于VS2017构建，但这似乎需要更多时间才能提交到上游的修复程序。

你好！
由于缺少C运行时库，我们在客户环境中遇到问题。
这个问题的状况如何？

解决方法是将C运行时安装在所有未与操作系统一起安装的客户端系统中。
只要Microsoft本身支持这些版本，我们就不能强迫客户这样做或从Windows Server 2012 R2升级到较新版本。

//编辑：
同时还有其他解决方法吗？