On Wed, 16 Feb 2022 16:46:47 GMT, Kevin Rushforth <k...@openjdk.org> wrote:
> The `javafx.graphics` module has a number of native libraries, including the > redistributable Microsoft DLLs on Windows. When running an application using > the standalone JavaFX SDK, we load all of the needed DLLs from the SDK `bin` > directory and everything works as expected. > > When creating the jmods, we currently exclude the Microsoft DLLs from > `javafx.graphics.jmod` to avoid the problem described in > [JDK-8207015](https://bugs.openjdk.java.net/browse/JDK-8207015) where `jlink` > complains about two modules (`java.base` and `javafx.graphics`) deliver the > same file(s). That works as long as the set of Microsoft DLLs delivered by > the JDK is from the same or newer version of Microsoft Visual Studio. This > means that you can't take, for example, JDK 11.0.x and run the latest version > of JavaFX, since JDK 11.x uses VS 2017 and JavaFX 15 (and later) uses VS 2019. > > Up until now this has just been a minor bug, but we are now at the point > where we need to update to VS 2019 for building JavaFX 11.0.15, which means > that a jlinked JDK 11.0.X + JavaFX 11.0.15 will no longer work. > > This fix is to add the Microsoft DLLs back into `javafx.graphics.jmod` (i.e., > stop excluding them at build time), but deliver them in `bin/javafx` so they > don't conflict with the ones delivered by the JDK. > > The changes are: > > 1. `build.gradle` - When creating the jmods on Windows, copy all of the DLLs > to a javafx sub-directory > 2. `NativeLibLoader.java` - in the case of JavaFX modules jlinked into the > Java runtime, load the libraries first from `${java.home}` rather than always > falling back to `System::loadLibrary`. Most of the changes are just simple > refactoring. The additional logic is in the new `libDirForJRT` method. > > When running using the SDK or the modules on maven central, there is no > change in behavior. > > I've tested this on all platforms, including a test of a custom JDK 11.x > created with jlink. On a Windows I tested it on a system where a key VS 2019 > runtime library was not present in C:\Windows\System32 and it now runs. Marked as reviewed by arapte (Reviewer). ------------- PR: https://git.openjdk.java.net/jfx/pull/734
