JDK-8210089 : Stop redistributing Microsoft DLLs in openjfx
  • Type: Bug
  • Component: javafx
  • Sub-Component: build
  • Affected Version: openjfx12
  • Priority: P3
  • Status: Closed
  • Resolution: Won't Fix
  • Submitted: 2018-08-28
  • Updated: 2020-05-06
  • Resolved: 2020-05-06
Related Reports
Blocks :  
JDK-8209966 - Update minimum boot JDK to 11
Relates :  
JDK-8242508 - Upgrade to Visual Studio 2019 version 16.5.3
Relates :  
JDK-8207015 - jlink javafx.graphics on Windows fails: PluginException: Duplicate resources
Description
JDK 11 distributes the Microsoft DLLs from the VS 2017 compiler and the Windows 10 SDK. Once openjfx requires JDK 11 to build and run (see JDK-8209966), we need to remove the build logic that includes these files in the openjfx build.

Note that we have already had to fix one bug to remove these files from the jmods because of the duplication of files between the JDK and FX. This may prevent similar problems, and in any case will simplify our build.
Comments
Closing as "Won't fix" for the reasons listed above.
06-05-2020
I think Phil is right: as an unbundled library, JavaFX should continue to ship the required DLLs. With a likely upgrade to VS 2019 coming soon for both the JDK and JavaFX, we will have problems testing and running JavaFX 15 with JDK 14 after the upgrade (and possibly vice versa, although that seems less likely unless Microsoft has broken backward compatibility, which they are usually very good at preserving). I recommend to close this as "Won't fix".
11-04-2020
Johan: You can decide whether / when to do this. If you do, then you might consider keeping most of the logic in place, and just disabling the gradle logic that copies the DLLs to modules/javafx.graphics/build/module-lib/ if (IS_WINDOWS) { from ("${graphicsProject.buildDir}/libs/prismD3D/${t.name}/${library(targetProperties.prismD3D.lib)}"); targetProperties.VS2017DLLs.each { vslib -> from ("$vslib"); } targetProperties.WinSDKDLLs.each { winsdklib -> from ("$winsdklib"); } }
28-08-2018
I agree that we don't want to statically link, both for footprint reasons and because Microsoft actively discourages it. It is a good point about whether an unbundled library should rely on the JDK to distribute these libraries, since that could change in the future and we might be scrambling to put them back. We should investigate this before making any decision.
28-08-2018
I am not sure of the extent to which Microsoft discourage that, but we'd take a footprint hit doing that as each of our native libraries would grow and I don't know if we'd end up with a bigger overall distribution or not. We did this in the past with the JDK for the C++ runtime, because JDK used only a tiny fraction of it, and so there was only a small increase in one (?) JDK DLL. As an unbundled library, I am not sure if removing the DLLs we need to run is the right thing to do. If JDK upgrades to VS 2019 (a hypothetical situation and release but possible), then openjfx11 or 12 would not run without providing its own libraries. Even if we said openjfxNN is supported only on openjdkNN, what is to stop JDK NN from changing compilers in its life - possible for the LTS releases ?
28-08-2018